Guidelines for Graduation Reviews

See "6.3.2 Graduation Review" and "6.3 Reviews" in the Eclipse Development Process
The purpose of the Graduation Review is to confirm that the Project is/has:
  • a working and demonstratable code base of sufficiently high quality
  • active and sufficiently diverse communities: adopters, developers, and users
  • operating fully in the open following the Principles and Purposes of Eclipse
  • a credit to Eclipse and is functioning well within the larger Eclipse community

(1) What are the Requirements?

R

The criteria for graduating from Incubation to Mature include:

  • A working and demonstrable code base with extensible frameworks and exemplary tools (see [1]).
  • Active communities (see [2]).
    • An active framework user (plug-in provider) community.
    • An active tool user community.
    • An active multi-organization committer/contributor/developer community.
  • The project is operating fully in the open using open source rules of engagement, e.g.,
    • Open and transparent Bugzilla with a described and documented bug process.
    • Open and transparent project schedules.
    • The project has working policies and procedures for developing, specifying, testing, and getting feedback on APIs.
    • The project decision making processes are published, and all project decisions are being made in public.
  • The project team members have learned the ropes and logistics of being an Eclipse project. In Apache parlance, the project "gets the Eclipse way".
    • Abiding by the base Eclipse Development Process as well as the additional rules defined by the EMO.
    • Adherence to the Eclipse IP Policy including an assesment of how well each Committer is following the committer responsibilities and due diligence rules. It is every Committer's responsibility to learn, know, and follow these rules.
    • Participating in the larger Eclipse community. For example, teaching tutorials at EclipseCon or other conferences, writing articles, participating in the Reviews of other projects, etc.
    • Working with other projects in its enclosing top-level Project.
    • The project is a credit to Eclipse and is functioning well within the Eclipse community.
  • An in-depth review of the technical architecture of the project, and its dependencies and interactions with other projects.

The project lead(s) are responsible for requesting a Graduation Review when the project leadership believes the project meets the exit criteria. The EMO will evaluate the request and act appropriately. Projects that are not making sufficient progress towards graduation will be at first gently, then, over time more forcefully, reminded that no action is the same as negative action.

(2) Preparing the Docuware

The "docuware" for a Review has traditionally been a slide deck however there is no reason to use slides: a short report/document would work equally well if not better (reports are information dense relative to slides, and that's a good attribute).

R
In any case, the docuware must be/have:

  • Neutral File Format. The docuware must be published in an operating-system neutral file format. PPT and DOC files are not considered neutral. PDF is currently the best choice and thus we require docuware to be published in PDF. The EMO can convert Open Office and Microsoft Office to PDF if you are unable to do so.
  • Archival Quality. The docuware must be comprehensible and complete on its own without requiring explanation by a human presenter. Archival quality is required because the docuware will be available on the eclipse.org website in perpetuity; future Eclipse users, adopters, and even new project committers will consult it long after the review conference call has been completed.
  • Correct Copyright and License. The docuware is being written (and thus copyrighted) by you, not by the Eclipse Foundation, and thus the copyright statement needs to be by you (or your employer). Similarly, the content should be licenses under the EPL.
  • Usable for a Phone Conversation. Remembering that most conversations about the docuware will be done over voice, email, IM, or other electronic media - not in a face-to-face situation - the docuware must have page and/or paragraph numbers so that the two parties in conversation can easily refer to the same section or slide.

R
The docuware must cover the issues from above especially the formation and viability of the three communities. Most projects combine their Graduation Review with the Release Review of their 1.0 release, in which case the docuware must also cover the Release Review issues.

(3) The Review Process

Once the review content has been created, the operational side of a Gradation Review is:
  1. Schedule the review by sending email to emo@eclipse.org.
    • Reviews are scheduled at most twice a month, usually on Wednesdays, usually in the morning (USA)/afternoon (Europe)/night (Asia).
    • Reviews are grouped up to four at a time.
  2. At least one week in advance of the review, you (the project lead) sends the docuware to emo@eclipse.org for posting.
    • The EMO posts the docuware via the website (through the wonders of database-driven web pages, the docuware is automatically linked from the review notice).
  3. At least one week in advance of the review, the EMO creates a bugzilla entry for discussion and advisory voting by the membership. (See example.)
  4. The EMO announces the reviews:
    • via the eclipse.org/projects web page (as soon as the review is scheduled)
    • via the reviews and announcements RSS feed (as soon as the review is scheduled and again when the docuware is posted)
    • via email to the committers and membership-at-large mailing lists (at least one week in advance of the review conference call)
    • The review conference call is held at the scheduled time.
      • The project lead must attend the call.
      • The proposal's mentors must attend the call.
      • These calls tend to be short (5-10 minutes). The purpose of the call is for the team to answer any questions from the community that have not otherwise been answered by the written material and/or discussions in the newsgroup.
    • After the call, a one-to-two week open discussion and advisory vote is held via the previous posted bugzilla.
      • A successful advisory vote requires at least three +1s from the Membership external to the project's Leadership Chain (i.e., the proposers listed in the proposal and the members of the destination PMC do not count for these three +1s. They should vote, of course, to show their support for the proposed project.)
      • A successful advisory vote requires at least one +1 from each level of the project's Leadership Chain (i.e., the project lead and one member of the destination PMC).
      • A successful advisory vote requires no upheld -1s. An Upheld -1 is a -1 that is followed within 24 hours by open, transparent, and public justification, and that justification is accepted by the EMO. Rejected -1s count as 0s.
      • A successful advisory vote requires +1s from each of the Project's Mentors.

(4) After a Successful Review

After a successful advisory vote and the approval of the Graduation Review by the EMO:
  1. the EMO will send email to the project developer mailing list with the approval
  2. the project can remove the "incubation" labeling and logos from their website pages
If the Graduation Review was also a Release Review, see "after successful review" notes those reviews.

 

Report flaws and request clarifications through bugzilla