Write implementation code for each class you've designed (adjust architecture as needed, of course.)

This is where you put the API reference, or all the parameter options, or whatever gory details your project requires. If this is a Puppet module, put this documentation in REFERENCE.md using these instructions.

Create the initial release. Depending on the type of project, this might mean writing your .gemspec and building a gem or it might mean writing a metadata.json for a Puppet module.

Implement feature and unit tests as you're building out your class structure.

Add usage documentation to your README.md as appropriate. Remember that usage instructions are not the same thing as a reference. Write this section from a more high level and/or conceptual standpoint for a reader who just discovered your project 90 seconds ago.

If you plan on internationalizing your project, set up the framework for doing so.

Think back to your charter. You identified some metrics that would identify whether this project was a success or not. With the release next week, how will you measure these metrics? How will you identify course corrections for the future? Put together a quick plan for answering these three questions:

• Did the project fully solve the problem that it was designed to address?
• What can you do next to iterate and deliver more benefits?
• What lessons did you learn for future work on this or other projects?

This can be as formal or not as you choose. If your chosen success metrics orient around download count or repository forks, then maybe all you need is a comment closing this issue with a link to your repository insights. If something more formal would help you, then write out your plan and determine how you'll execute on it.

Remember that you can ask Puppet project managers for advice, and you can reach out to individuals you've worked with to provide feedback on the process and the project.

Configure your spec testing framework. If this is a Puppet module, the PDK will have done this for you automatically.

We will have time slots for presenting projects at Contributor Summit. If you'd like to participate, then put together a few words describing the problem that your project solves and how it works. You might have time for a few slides or a quick demo, depending on how many projects want to present.

Remember, this isn't a comprehensive exposé of every possible thing your project does. As it's often said, "The purpose of an elevator pitch is to describe a situation or solution so compelling that the person you're with wants to hear more after the elevator ride is over." Create some excitement!

The project directory should be created with all the needed directories and support files. If you're creating a Puppet module, the PDK should be used for this!

Edit the issue queue on this repository to match the needs of your project. Add issues as needed, remove or close irrelevant issue, move the issues between milestones, etc.

If your project is a thing that requires installation, then write installation & configuration docs. Remember your audience--this might just be gem install <projectname> or it might be more involved. Remember to document any dependencies or required setup.

Mission: What are you building or solving ?

I would like to setup multi hosts acceptance tests with beaker for module voxpupuli/openvpn.

For the moment, i enabled a minimal acceptance tests set with only one puppet node. But, with openvpn we have to support server and client side. We can not test well with server and client on same node.

End users: Who will derive value from what you're building? How will you reach them?

My work will be reviewed by others members of Voxpupuli. I can reach them but IRC as usual.

Vision: Why build this? What transformational change will this encourage?

In VP modules, we do not have any module running acceptance tests with several nodes. This module will show to others how to build acceptance tests with several nodes.

Success criteria: How will we know if we've succeeded?

• 1st step : at the end of this summit , the module will have acceptance tests running with several nodes.
• 2sd step : after the end of the summit (or during, it depends of time consumed by step 1) , it will be possible to test effectively around the issue declared here : voxpupuli/openvpn#211
• 3rd step : out of this summit, others contributors and VP collaborators can use multi node tests when it is needed.

Constraints: What non-negotiable constraints must be navigated?

I am in France and so, with time shift, it can be difficult to talk synchronously with Portland.
Even if i use puppet for my job, i work about this on my free time.
I am more ops then dev.
My work station is with Linux.

Assumptions: What assumptions are we making that might affect our success if they were to change?

N/A i suppose.

Team members: Who is working on the project? Are there any other stakeholders?

I work alone on this project. I said on IRC i registered about this topic, and online peoples reacted positively. As always, i can talk with others online VP members.

Write a user-facing README.md that describes the project. You can use the charter as inspiration. You'll come back to it and add installation and usage docs later, but for now an end user reading this should be able to understand what the project is and what it does.

Now that you've built a few things and you've had some time to gather feedback, it's time to design a roadmap for the future. We're going to make our initial releases next week, so now it's time to start thinking about what happens next.

Where do you want to go? Is it time to iterate and build a more complete and mature solution? Should the first release be discarded and lessons learnt guide a redesign?

Add more milestones for future releases and then put together some of the high level issues to describe your plans.

Decide how to structure your project and create initial class files/manifests/etc as appropriate.