|
|
|
|
|
# Candidate Proposal
|
|
|
|
|
|
This document describes approaches to drawing up a proposal for submission. It is not an inflexible standard but represents a consensus condensed from OMC discussions. Feel free to modify the template when submitting your proposal.
|
|
|
|
|
|
It's not required to have a good proposal but having a good proposal will increase the chances of a positive outcome. A good proposal should shape the future evolution of the project. Still, each proposal only captures the 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.
|
|
|
|
|
|
## Formulating A Proposal
|
|
|
|
|
|
### Project Name
|
|
|
|
|
|
While it is important to come up with a [suitable project name](http://incubator.apache.org/guides/graduation.html#notes-names) 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.
|
|
|
|
|
|
### Presentation
|
|
|
|
|
|
Once you have a draft proposal, it should be presented to the OMC. _Currently, post the proposal to the R3 Shared Backlog team via Slack to initiate the presentation of the proposal._ If there is interest in the proposal, expect a lively debate to begin. Approval follows a vote to formally be recognized as an incubating podling. Discussion is an important part of opinion formation. A proposal will require development if it is to gain the maximum level of support from the community.
|
|
|
|
|
|
### 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.
|
|
|
|
|
|
Gitlab 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 Slack or appropriate mailing list.
|
|
|
|
|
|
### The Vote
|
|
|
|
|
|
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. |
|
|
\ No newline at end of file |