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.
Commentary: A short descriptive summary of the project. A short paragraph, ideally one sentence in length. The abstract should be suitable for reuse in the board resolution used to create the official project upon graduation, as the first paragraph on the podling web site and in the DOAP document.
Commentary: A lengthier description of the proposal. Should be reasonably declarative. More discursive material should be included in the rationale (or other later sections).
Commentary: Provides context for those unfamiliar with the problem space and the history of the project. Explain terms whose meanings may be misunderstood (for example, where there is not a single widely adopted definition). This content should be capable of being safely ignored by domain experts. It should probably find an eventual home on the Podling website.
Commentary: Explains why this project needs to exist and why should it be adopted by OSDU. This is the right place for discursive material.
Commentary: A complex proposal (involving multiple existing code bases, for example) may cause concerns about its practicality. A good way to address these concerns is to create a plan that demonstrates the proposal is feasible and has been carefully thought through.
Many projects will not need this section.
Commentary: This section (and the contained topics) describes the candidate's current status and development practices. This should be an honest assessment balancing these against Apache's principles and development ideals.
For some proposals, this is a chance to demonstrate an understanding of the issues that will need to be addressed before graduation. For others, this is a chance to highlight the close match with Apache that already exists. Proposals without an initial code base should just simply state that.
Some proposals name this section criteria (though the term is a little misleading).
Commentary: OSDU is a meritocracy.
Once a developer has submitted enough good patches, then it should be natural that they are elected to committer. It should be natural that active committers are elected to the project management committee (PMC).
This process of renewal is vital to the long-term health of OSDU projects. This is the right place to demonstrate that this process is understood by the proposers.
Commentary: OSDU is interested only in communities.
Candidates should start with a community and have the potential to grow and renew this community by attracting new users and developers. Explain how the proposal fits this vision.
OSDU projects are composed of individuals.
It is useful to provide a brief introduction to the developers on the initial committers list. This is best done here (and not in that section). This section may be used to discuss the diversity of the core development team.
Describe why OSDU is a good match for the proposal. An opportunity to highlight links with other OSDU projects and development philosophy.
An exercise in self-knowledge. Risks don't mean that a project is unacceptable. If they are recognized and noted, then they can be addressed during incubation.
A public commitment to future development.
Recruiting a diverse development community and a strong user base takes time. Open Group and OSDU forum need to be confident that the proposers are committed.
If the proposal is based on an existing open source project with a history of open development, then highlight this here.
If the list of initial committers contains developers with strong open source backgrounds, then highlight this here.
Inexperience with open source is one reason why closed projects choose to apply for incubation. Successfully opening a closed project means an investment of energy by all involved. It requires a willingness to learn and to give back to the community. If the proposal is based around a closed project and comes with very little understanding of the open source space, then acknowledge this and demonstrate a willingness to learn.
Commentary: This section describes how long the project is expected to be in incubation before it's graduation as a top-level project and the reasons for that.
This shows the project has thought about the steps required to graduate and that there are not any unrealistic expectations.
Healthy projects need a mix of developers. Open development requires a commitment to encouraging a diverse mixture. This includes the art of working as part of a geographically scattered group in a distributed environment.
Starting with a homogenous community does not prevent a project from entering incubation. But for those projects, a commitment to creating a diverse mix of developers is useful. Those projects who already have a mix should take this chance to highlight that they do.
OSDU projects should be open to collaboration with other open source projects both within OSDU and without. Candidates should be willing to reach outside their own little bubbles.
This is an opportunity to talk about existing links. It is also the right place to talk about potential future links and plans.
OSDU allows different projects to have competing or overlapping goals. However, this should mean friendly competition between codebases and cordial cooperation between communities.
It is not always obvious whether a candidate is a direct competitor to an existing project, an indirect competitor (same problem space, different ecological niche) or are just peers with some overlap. In the case of indirect competition, it is important that the abstract describes the niche accurately. Direct competitors should expect to be asked to summarize architectural differences and similarities to existing projects.
References to further reading material.
Describes the origin of the proposed code base. If the initial code arrives from more than one source, this is the right place to outline the different histories.
If there is no initial source, note that here.
Complex proposals (typically involving multiple code bases) may find it useful to draw up an initial plan for the submission of the code here. Demonstrate that the proposal is practical.
External dependencies for the initial source are important. Only some external dependencies are allowed by Apache policy. These restrictions are (to some extent) initially relaxed for projects under incubation.
If the initial source has dependencies which would prevent graduation, then this is the right place to indicate how these issues will be resolved.
If the proposal involves cryptographic code either directly or indirectly, Open Group needs to know so that the relevant paperwork can be obtained.
It is conventional to use all lower case, dash-separated (-) repository names. The repository should be prefixed with incubator and later renamed assuming the project is promoted to a TLP.
Apache runs JIRA and Bugzilla. Choose one. Indicate the name by which project should be known in the issue tracking system.
Describe here any other special infrastructure requirements necessary for the proposal. Note that the infrastructure team usually requires a compelling argument before new services are allowed on core hardware. Most proposals should not require this section.
Most standard resources not covered above (such as continuous integration) should be added after bootstrapping. The infrastructure documentation explains the process.
List of committers (stating name and an email address) used to bootstrap the community. Mark each which has submitted a contributor license agreement (CLA). It is a good idea to submit CLAs at the same time as the proposal.