chadh / puppet-cso-project Goto Github PK

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.

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.

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!

A project charter is a quick but complete description of the problem you are solving, who it's targeted at, and what the success criteria are. It should be simple, compelling, visible, and kept current. In many open source projects, the charter is most visible as the README or as the introduction section.

A good charter will help you define what success means, and will help you to focus only on tasks that will further this success. This exercise will help ensure that at the end of the month, you'll have something you're proud to release.

The elements of a complete charter for an open source project are listed below. Simplify as appropriate when writing your own. Your charter should be no more than a few paragraphs or a handful of bullet points.

• Mission: What are you building or solving?
• End users: Who will derive value from what you're building? How will you reach them?
• Vision: Why build this? What transformational change will this encourage?
• Success criteria: How will we know if we've succeeded? Note that this is not simply a list of deliverables, but whether the end result accomplished our vision.
• Constraints: What non-negotiable constraints must be navigated?
• Assumptions: What assumptions are we making that might affect our success if they were to change?
• Team members: Who is working on the project? Are there any other stakeholders? Describe roles rather than names, if you can.

See this blog post for a more complete description.

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.

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

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.

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.

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

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

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!

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.

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

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.

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.

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