Guide :: A Guide To Proposal Creation

Entry to the incubator is a process decided by a vote. The proposal is the document upon which the Sponsor (usually the incubator) votes. Having a good proposal increases the chances of a positive outcome.

Proposals to the incubator generate attention. The general mailing list is open, widely discussed, and well indexed. It is a very public space. A good proposal should target the wider audience and not just the IPMC. Use this time to engage and inform potential developers and users.

A good proposal should shape the future evolution of the project. Still, each proposal only captures the particular details of the project at its birth. We understand that projects change and evolve.

The incubation process is continuously evolving. We hope this will help newer projects to be even stronger and more successful than existing ones. One consequence of this approach is that what previous podlings have done, even those that are now TLPs, may not be a reliable guide. Another is that documentation may be a little outdated.

Help improve the system by posting a patch for this document to the incubator section of Jira or a comment to the general list, or raise a pull request at the incubator site repository.

Start with research. The Cookbook is a good place to start. Read the Apache documentation.

Subscribe to the general mailing list. Spend some time reviewing the email lists archives. The email lists are the standard forum for communication and decision-making at Apache.

Before starting on the formal proposal, recruit a Champion. The Champion understands Apache and should be able to help you navigate the process and put your proposal together.

Review recent proposals and how they have been received. Check to see which podlings have become Top Level Projects (TLPs) and which have not. Read up on some of the issues a podling may face while in incubation.

The incoming community needs to work together before presenting this proposal to the Incubator. Think about and discuss future goals, and the reasons the project is wants to come to Apache. Feel free to ask questions on the Incubator general@ list.

Every proposal is different. There will always be some aspects of a project which do not seem to fit well into the template. Use the template as a guide but do not feel constrained by it. Adopt what works and change what doesn’t. It is fine to do that.

Be sure to add your proposal to this list. You can copy the existing template for your new proposal.

You must come up with a suitable project name and product names before entering incubation. Be careful not to disrupt your proposal and entry process. But also be aware that changing your name may be required at some point, and that could be disruptive to your community.

Once you have a draft proposal, present it to the incubator. Post the proposal in plain text in an email to the email list with a subject line prefixed with [PROPOSAL]. You should be clear that you want to discuss your proposal when submitting this email.

If there is interest in the proposal, expect a lively debate to begin. Approval follows a vote to enter the incubator. Discussion is an important part of opinion formation. Most proposals require some rework and development to gain the maximum level of support from the Incubator.

Expect to work on improving the proposal on the list after presenting it. No preparation can cover every question. It is usual for interested parties to pose unexpected and novel questions. So (though it may sometimes feel like an ordeal) approach these questions as a real opportunity to engage with the Incubator.

The wiki is a useful development tool. Consider creating a wiki page containing the evolving proposal content. Those who are interested should add themselves to the watch list for the page so they can receive change notifications.

Developing the proposal on the wiki allows for easy collaboration. The wiki is just a tool to assist the development of the final proposal (the one that the PPMC will vote on). However, the wiki is not an appropriate forum for debating changes. Gently move discussion onto the appropriate email list.

Effective management of this development process is a good exercise in community building.

When the proposal seems finished, and some form of consensus has emerged, you can put the proposal to the vote.

If you use the wiki to develop the proposal, please ensure that the wiki page content matches the content of the final proposal then add a notice on the wiki page that development of the document is now complete. Change the wiki page to be read-only so nobody can make further changes.

Embed the final proposal text or include the final version number of the wiki proposal page in the email which starts the VOTE thread. If a change is required after the vote has been called then you must cancel the vote, make the change, and then start a new vote. Alternatively, Mentors will advise on how to make the change once the proposal has been accepted. Do not edit the wiki proposal page unless you have canceled the vote thread.