This guidance is distilled from real Apache Incubator proposal discussions and focuses on proposal accuracy around people, roles, participation, and ownership.

Who This Guide Is For

This guide is intended for:

• Project proposers
• Podling PPMCs
• Incubator mentors
• IPMC members

Use this guide to help check whether a proposal’s description of its community matches what can be observed and verified. Clear, accurate proposals reduce review friction and help discussions focus on whether a project is ready for incubation.

1. Describe Roles and Groupings Consistently

If a proposal lists people in different groups (for example, PPMC roles and committers), it should be clear:

• why those groupings exist
• what responsibilities are implied
• whether those roles reflect current practice or future intent

If the proposal uses labels such as “core maintainers” or “core developers”:

• the stated number should match the people listed
• any criteria used should be applied consistently across the proposal
• inconsistencies should be corrected promptly

Unexplained hierarchies or inconsistent counts can undermine confidence in the proposal.

2. Keep Repository References Accurate and Necessary

Proposals should reference only repositories that:

• exist at proposal time
• are required for the project as proposed

Unclear or unnecessary repository references are best removed until they are actually needed.

3. Avoid Arbitrary Contribution Thresholds

Be cautious about using rigid numeric thresholds for recognition or advancement (for example, time served, commit counts, or lines of code).

Concerns raised with this approach include:

• thresholds that may be unnecessarily high
• discouraging participation
• excluding non-code or other contributions

4. State Salaried and Volunteer Participation Clearly

If most contributors are salaried or affiliated with a single organisation, state this explicitly. Describe employment and participation reality accurately, without optimistic framing that is not supported by observable activity.

5. Make Committer Lists About Ongoing Participation

Committer lists should reflect who is willing to participate under ASF norms, rather than serving primarily as recognition for historical association.

6. Make Ownership and Donation Status Explicit

Where work is owned or controlled by an organisation:

• donation status should be addressed directly
• the presence or absence of a Software Grant Agreement should be clear

Leaving ownership implicit can create uncertainty during proposal review.

7. Avoid Inflated Community Size or Growth Claims

Claims about contributors, activity, or growth should be:

• based on observable public activity
• clearly explained
• free from ambiguous or inflated metrics

Accuracy and honesty are valued more highly than impressive-looking numbers.

8. Key Takeaways

• Role descriptions should be clear and internally consistent
• Repository references should be accurate and necessary
• Be cautious with rigid numeric bars for recognition or advancement
• State employment and ownership realities plainly
• Prefer verifiable claims over optimistic or inflated metrics