- What is Graduation?
- Whether to Graduate to Subproject or to Top Level Project
- Before You Graduate
- Ensure suitable project name and product names
- Creating an Apache Release
- Creating an Open and Diverse community
- The Graduation Process
- Graduating to a Subproject
The intent of this document is to help podlings understand the process of graduation and 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 projects 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 smooth.
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 project and requires the consent of the 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 shortlist 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
There are two distinct parts to making releases:
"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 and subsequent publishing the release.
"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 where they are picked up by the mirror system.
It is an important step during your stay in the incubator to demonstrate the ability to prepare and publish an Apache Release. That means 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 archive old releases
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 requires 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 3 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 that 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.
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 who 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
Graduation to a top level project requires:
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.
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.
The Recommendation Vote
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 by a post to the board mailing list. Posting from an Apache address is recommended. Mixing public and private lists on a post is not recommended.
The board list is private. The usual netiquette for Apache private lists should be observed. So, it is recommended that only the podling and IPMC private lists are CC’d (rather than the general incubator list). Please treat responses with appropriate confidentiality.
The submission should include: - A clear subject (for example Establish Foo TLP) - A brief introduction - The name of proposed VP - Links to the VOTE threads - Summary of the VOTE results - The resolution text
From: <you _at_ apache dot org> To: <board _at_ apache dot org> CC: <<project>-private _at_ incubator dot apache dot org> Subject: Proposed Resolution: Establish <project> TLP Dear Apache Board, <Project> is ready for graduation out of the incubator. So, please consider the draft resolution below at your next meeting. <thank you, best regards, personal note if you wish, etc etc> <your name> -- References: Home: <project home page> Vote by project: <link to vote thread on project list> Vote by incubator: <link to vote thread on general list> Resolution draft: <<resolution goes here, 72 characters wide, indent with 4 spaces>> -- <your e-mail sig, if you have one>
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
Graduation Approval Vote
Once the accepting TLP have voted to accept the podling and the podling has voted to become a subproject, noticed 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.
Please read the Guide to Transferring Resources out of the Incubator