This document describes approaches to drawing up a proposal for submission. It is not an inflexible standard but represents a consensus condensed from discussions on the general mailing list. Feel free to modify the template when submitting your proposal.
Entry to the incubator is a process decided by a vote. The proposal is the document upon which the Sponsor (usually the incubator) votes. It’s not required to have a good proposal, but having a good proposal will increase 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 at birth. It is understood that projects change and evolve.
The incubation process is continuously evolving. Hopefully, 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 TLP, may not be a reliable guide. Another is that documentation may be a little outdated.
Formulating A Proposal
Before starting on the formal proposal, recruit a Champion. The Champion understands Apache and should be able to help 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 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 for coming to Apache. Feel free to ask questions on the list.
Every proposal is different. There will always be some aspects 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.
While it is important to come up with a suitable project name and product names during incubation, it is a requirement to do this 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, it should be presented to the incubator. Post the proposal in plain text in an email to the mailing list with a subject line prefixed with [PROPOSAL]. You should be clear that you want to discuss your proposal when submitting this mail.
Developing The Proposal
Expect to work on improving the proposal on the list after presenting it. No preparation can cover every question. It is usual for unexpected and novel questions to be asked. These questions are often a sign of interest. 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 will be voted upon).
Effective management of this development process is a good exercise in community building. The wiki is not an appropriate forum for debating changes. Discussions should be gently moved onto the appropriate mailing list.
When the proposal seems finished, and some form of consensus has emerged, the proposal should be put to the vote.
If the wiki is used to develop the proposal, please ensure that the wiki matches the final proposal then add a notice to the wiki that development of the document is now complete. Change the wiki page to be read-only so that no further changes can be made.
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 the vote must be cancelled, the change made, and the vote restarted. Alternatively, Mentors will advise on how to make the change once the proposal has been accepted. Do not edit the wiki proposal unless you cancel the vote thread.
The aim of presenting a template with examples and comments is educational. Proposals are not required to adopt this format. Every proposal is different. There may be sections which don’t seem to be useful. It’s fine to miss them out and to add new ones that the proposal appears to need.
The format is less important than the content.