Estimated Reading Time:

The intent of this document is to help podlings understand the process of graduation and to offer some views about how to approach it. It also links to the Incubator exit policies. It is not an inflexible standard but represents a consensus condensed from previous discussions on the Incubator general list. It also describes some of the first steps that should be taken after graduation.

This is just a guide. Policy is stated here.

Help to improve the system by posting a patch for this document to the Incubator section of JIRA or a comment to the general list at Incubator.

What is Graduation?

Graduation is the act of a podling becoming either a subproject under an already existing Apache project, or becoming a top level Apache project. Graduating is a democratic process: in the end, it comes down to a VOTE. Note that during your stay in the Incubator, you are already busy with the process of Graduating: by adopting Apache procedures, growing and fostering your community, having (civil) fights concerning code style (tabs versus spaces), cutting releases and so forth. All these acts have an influence on your project’s graduation.

The road to graduation is pretty clear: depending on whether your project wants to become a top level project or join as a subproject under an already existing project, the steps are fairly simple but do take time and effort. This document provides guidelines for making this process run smoothly.

This document is offered for guidance and education only. Actual policy is documented in the Incubation PolicyGuide in this section. Please post any questions about graduation to the general Incubator list.

Whether to Graduate to Subproject or to Top Level Project

Each proposal has a Sponsor. The identity of the Sponsor indicates the natural destination. For proposals sponsored by the Board or by the IncubatorPMC (IPMC), this is a top level project. For others, this is as a subproject of the sponsoring project. However, the destination is fixed only on graduation, not entry. Projects grow and evolve during the graduation process. As graduation approaches, this original preference should be reviewed based on where the project is now.

Graduation as a subproject is only possible if the subproject still falls within the scope of the sponsoring project and requires the consent of that project PMC. Graduation as a top level project requires the formation of the new project by the Board.

The IPMC will also express a democratic opinion. For those seeking to graduate to a subproject this VOTE is to approve the transfer. For those seeking to graduation as a top level project, this will be a recommendation to the Board. Expect IPMC-ers to ask questions about the project including about the choice of destination. This is part of the normal process.

Before You Graduate

Before you start thinking about graduation, you need to make sure you are ready and meet the requirements imposed on Apache projects. This section will provide a short list for podlings to determine if they meet the criteria for asking graduation.

Graduation Check List

The following is a short checklist giving an overview, not a substitute for reading the content below.

Checking the Status File

The status file records and summarizes incubation-related information on the podling. The PPMC is responsible for keeping this file current. Before you are able to graduate, all tasks need to be completed.

The status file is a great way of keeping tabs on how your project is doing and what needs to be done to meet the graduation criteria. The Incubator PMC will check this file when they vote on the graduation of your project. Once all tasks are done and the listed criteria met, your project may be ready for graduation.

The status file of the JUDDI project is one example.

Ensure suitable project name and product names

Please read detailed documentation here. The "Process for ensuring suitable project and product names" is mandatory for every podling which wants to graduate.

Creating an Apache Release

Release Early, Release Often

— Eric Steven Raymond

There are two distinct parts to making releases:

  1. "Preparing a release" is something that is done by a release manager. Some documentation refers to this as "cutting" a release. Preparing a release means following the project-specific instructions for creating the release artifacts and putting them in a repository that is a staging area for voting on and subsequently publishing the release.

  2. "Publishing a release" is done after the podling and then the IPMC approve the release that has been prepared, using a formal [VOTE] process. If the vote fails, the release manager can prepare an improved release. Publishing means that the release artifacts are moved to the official distribution area.

It is an important step during your stay in the incubator to demonstrate the ability to prepare and publish an Apache Release. That means the graduating podling:

  • Knows the licensing requirements of what code is going into your source release

  • Knows where to stage the source release

  • Knows how to conduct votes on the releases

  • Knows how to remove links to old releases from its website

Please read the Incubator Release Management Guide for hints, tips and guidelines for making a release that will get approved by the IPMC without problems.

Creating an Open and Diverse community

A major criterion for graduation is to have developed an open and diverse meritocratic community. Time has demonstrated that these kinds of communities are more robust and productive than more closed ones.

Apache projects are self-sustaining and self-governing communities. Long term success and health require that these communities understand how to:

  • recruit users, developers, committers and PMCers

  • take responsible collective action

  • disagree in public on technical matters without destroying personal relationships

  • create an open, positive and inclusive atmosphere on the mailing lists

Graduation tests whether (in the opinion of the IPMC) a podling has learned enough and is responsible enough to sustain itself as such a community.

Read more on how to successfully build an open and diverse community for your podling in the community guide.

As a project grows, it needs to renew itself by accepting new committers. A project needs to learn how it can recruit new developers and committers into the community. Accepting new committers usually increases the diversity of the project. So, this process is very beneficial. Community building requires energy which could have been spent on code development, but this cost is an important investment for the future of the project.

The openness of the community is not only measured by the number of contributors. Open and respectful discussions on the mailing lists are vital. Ways to resolve technical conflict without destroying personal relationships must be learned. Learning to use mailing lists effectively is very important. If this can be achieved, then you have shown to be a lively, active and successful community. The future looks bright.

The project is considered to have a diverse community when it is not highly dependent on any single contributor (there are at least three legally independent committers and there is no single company or entity that is vital to the success of the project). Basically this means that when a project mostly consists of contributors from one company, this is a sign of not being diverse enough. You can mitigate this requirement by admitting more external contributors to your project who have no tie to the single entity.

Growing an open and diverse meritocratic community is not something that just happens: it takes work. Read the building a community guide for guidelines, hints and tips on how you can accomplish this for your project.

Other Issues

The Incubator relies more on people than rules: rather than try to create rules to cover every circumstance, rules are developed and codified as required. People are trusted to evolve process and policy. This guide can only document the most common issues and it is possible that there are other concerns that may require resolution that are not covered.

Podlings that are unsure if they are ready to graduate may want to consider completing the Apache Project Maturity Model. You may find this to be a useful guide when looking at various factors in your podling’s community.

The Graduation Process

Graduating to a Top Level Project

Top level projects are created by the Board. The Incubator Project Management Committee (IPMC) can therefore only recommend to the Board that the project is ready to graduate to a top level project.

Graduation to a top level project requires:

  • a charter for your project

  • a positive community graduation VOTE

  • a positive IPMC recommendation VOTE

  • the acceptance of the resolution by the Board

This process can take a while, since it typically sparks some discussion inside the community and possibly in the IPMC.

Here’s an estimated timeline for the graduation process. It should help you understand when you should start ramping up your community to get timely graduation and make the process smooth.

Graduation timeline

For each event we scheduled one or two weeks. Even though a VOTE is usually limited to 72 hours, you should prepare for discussion and possibly having to cast a revote with a revised proposal.

Community Graduation Vote

A community needs to be willing to govern itself before it can become a top level project. A good way to demonstrate this is through a free VOTE (by the community) on the graduation proposal.

This VOTE is not a requirement but is recommended. It is unlikely that IPMCmembers will vote to approve graduation unless the Mentors and community positively express their readiness for graduation. It is wise to notify the incubator general list that the community vote is starting. Please do not CC the vote to the general list as that creates confusion. Instead you can either: - FWD the [VOTE] e-mail to the general list, or - Send a different copy to the general list indicating that a graduation community [VOTE] is in progress

Preparing a Charter

So, in this case a suitable Board resolution should be drawn up by the community advised by the Mentors. Committers can access the podling template for resolutions in the committers svn repository. Your whimsy roster also includes a feature to draft a resolution. Also, resolutions are included in the Board minutes, which are posted publicly here . These contain numerous examples.

The original proposal and the status document should be consulted when creating this document. Projects evolve over time and some deviation from the original proposal may well prove acceptable. The Board resolution is the ultimate definition of the scope of an Apache project. So it is important that it reflects the vision for the project as it appears on the eve of graduation.

A good resolution is neither too narrow nor too broad. If the project’s scope is too narrow, then its activities will be unnecessarily constrained. If a project’s scope is too broad then it may lack focus and suffer from governance issues.

If you read these resolutions you also see that you need to appoint a Chair for your project. It is up to the PPMC to choose one person to act as the chair after graduation.

The Recommendation Vote

The resolution should be proposed on the general incubator list before a VOTE is started to allow feedback. Once a consensus has been reached, a VOTE should be started on the same general Incubator list by a member of the PPMC proposing that the IPMC recommends the resolution to the Board.

Submission of the Resolution to the Board

Top level projects are created by a resolution by the Board. Once the resolution has been finalized and consensus reached, it should be submitted to the Board. For inclusion in the agenda for the next meeting, the resolution should be submitted at least 72 hours before that meeting. A calendar for meetings is available.

Business for the Board should be submitted using the Whimsy Board Agenda tool.

Use the 'add item' button on bottom of the page and choose 'Establish Project'. The template requires the project name (without the 'Apache' prefix) plus a brief description of the project. When entering the proposed PMC members, add the proposed PMC chair first.

When you submit the resolution data, you will be presented with the text of the board resolution which can be edited to fix any issues before you finalize the submission.

Please try to keep the board list traffic low. Do not submit reminders or ask whether messages have been received on the list. Apache Members have access to the Board archives and may observe Board meetings. To follow the progress of a resolution, please ask a friendly Mentor, Member or Director.

Press Releases for new TLPs

Once there is clear consensus that the recommendation will happen, a member of the PPMC should contact ASF Marketing & Publicity at press(at)apache(dot)org if your project is interested in a formal press release announcing your graduation. This should be done roughly at the same time that the board resolution is sent.

Graduating to a Subproject

Subprojects are accepted by a Project Management Committee. The Incubator Project Management Committee needs to approve the graduation of the podling to a subproject.

Community Graduation Vote

Becoming a subproject is a voluntary process, and should be accepted by the community becoming a sub-project. It should be clear to the PPMC and committers for the podling what the make up of the new sub-project should be, e.g. who belongs on the receiving PMC, who will be a committer. Due to this nature, it is important that the podling votes to become a sub-project. This vote should happen on a public dev list.

Subproject Acceptance Vote

A formal VOTE by the Project PMC to accept the podling as a subproject is a prerequisite. Sometimes, projects may feel that the podling has grown too big and would be better as a top level project. The Chair of the project is the right contact.

Graduation Approval Vote

Once the accepting TLP has voted to accept the podling and the podling has voted to become a subproject, notice should be sent to the IPMC via general AT incubator.a.o email list indicating that the podling will become a subproject. If after 72 hours no issues are raised, the podling may be considered a subproject of the accepting TLP. Likewise, if any IPMC member raises an issue, that should be discussed. If the issue is addressed, the member raising the issue should indicate they rescind their concerns or otherwise consider them resolved.