This guide is distilled from real Incubator graduation discussions. It focuses on patterns that commonly appear during graduation review. All examples have been generalised.

Who This Guide Is For

This guide is intended for:

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

This guide is most useful for communities that are approaching graduation or considering whether they are truly ready. It is not a checklist of formal requirements, but a practical summary of issues that often surface late in the process.

1. Why Graduation Reviews Find “Last Minute” Issues

Graduation reviews can surface issues that were not caught earlier, especially around:

• branding and use of the project name
• domains that are not under ASF control
• download pages and release presentation
• how major components and ecosystem artifacts are presented

The graduation review is the final structured point at which a wider group examines how the project is presented to users.

2. Domains and Official Presence

Domain questions can arise at graduation:

• Is there a non-ASF domain that appears to be the official project site?
• Who owns that domain, and who can change it?
• Has appropriate ASF permission been obtained for any non-ASF domain that uses Apache marks?
• Could users reasonably mistake a third-party site for the Apache project?

Graduation reviewers typically look for:

• A clear primary presence under ASF-controlled domains.
• Any non-ASF domains using the name to be clearly separate or explicitly approved.

3. Branding in Ecosystems and Third-Party References

Branding concerns can show up outside the main website, for example:

• Container images labelled or described in a way that implies they are official Apache releases when they are not.
• Package pages in common registries that omit proper Apache attribution or create ambiguity about project identity.
• Third-party documentation or promotional material that could be mistaken for official Apache project material.
• Vendor branding is presented so prominently that users may confuse the Apache project with a vendor product.

In a graduation review, reviewers typically look for evidence that the project community actively manages project-owned materials and addresses misleading presentations when they are identified.

4. Download Pages and Release Presentation

Download pages can block graduation, but they are easy to fix. Typical issues include:

• Linking to artifacts without using standard ASF download mechanisms.
• Missing or hard-to-find KEYS files.
• Linking to repository commits or nightly artifacts as if they are releases.
• Presenting old releases as current, rather than clearly archived or marked as historical.

Reviewers often look for download pages that follow ASF Infra guidance.

5. Releases, Major Components, and Coverage

Release history is examined closely at graduation. Concerns can include:

• A significant part of the codebase that users reasonably see as part of the project has never had an Apache release.
• Very few releases overall, given the project's age.
• Only one person has acted as release manager.

6. PMC Composition and Community Signals at Graduation

Graduation also prompts a review of whether the proposed PMC reflects the real community:

• A large number of contributors, but relatively few new committers or PMC members.
• Inactive people are being proposed for PMC without a clear recent record of participation.

Typical questions include:

• Has responsibility spread beyond a small core?
• Are the people proposed for PMC doing the work now?
• Does the proposed PMC reflect current stewardship?

7. How Concerns Are Raised and Resolved in Graduation Reviews

Graduation discussions can include:

• Specific, concrete concerns about domains, download pages, branding, or unreleased major components.
• Questions or suggestions raised with the expectation that they will be addressed during the DISCUSS period.

Patterns that matter:

• Raising policy, branding, or distribution concerns during graduation review is normal.
• Some issues may be treated as blockers until addressed, particularly those that affect user trust in Apache releases or confuse project ownership.
• Projects that respond quickly, acknowledge issues, and describe a concrete fix tend to build confidence.

How the community responds to graduation feedback is itself a signal of maturity.

8. Practical Use for Podlings and Mentors

Before starting a graduation vote, it helps to check:

• Are download pages following ASF Infra guidance, including ASF hosts, signatures, checksums, and KEYS?
• Are there non-ASF domains or ecosystem artifacts that could be mistaken for official Apache project outputs?
• Have all major components had at least one proper Apache release?
• Does the proposed PMC list reflect who is actively doing the work now?

It is better to fix these sorts of issues before, rather than during, the graduation review.

9. Key Takeaways

• Graduation reviews often surface presentation and governance issues that went unnoticed during incubation.
• Domains, branding, and download presentation are common sources of late-stage concern because they directly affect user trust.
• Major components that users associate with the project should have proper Apache releases before graduation.
• The proposed PMC should reflect the current, active stewards of the project rather than historical contributors.
• Addressing concerns promptly and transparently during graduation review is a strong signal of project maturity.