Jump to: navigation, search

Difference between revisions of "Development Resources/HOWTO/Criteria for Graduating from Incubation Phase to Mature Phase"

(New page: The criteria for graduating from Incubation to Mature include: * A working and demonstrable code base with extensible frameworks and exemplary tools (see [http://www.eclipse.org/project...)
 
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
The criteria for graduating from Incubation to Mature include:
+
The Technology PMC is developing a new set of guidelines: [[Community_Development_for_Eclipse_Projects]]
 +
 
 +
The existing (or older) criteria for graduating from Incubation to Mature include:
  
 
* A working and demonstrable code base with extensible  frameworks and exemplary tools (see [http://www.eclipse.org/projects/dev_process/incubation-phase.php#CodeBase]).
 
* A working and demonstrable code base with extensible  frameworks and exemplary tools (see [http://www.eclipse.org/projects/dev_process/incubation-phase.php#CodeBase]).
Line 25: Line 27:
 
forcefully, reminded that no action is the same as negative action.
 
forcefully, reminded that no action is the same as negative action.
  
''This page is moderated by Anne Jacko and Bjorn Freeman-Benson (Eclipse Foundation)''
+
''This page is moderated by the EMO''
 
[[Category:Development_Resources]]
 
[[Category:Development_Resources]]
 
[[Category:How to Contribute]]
 
[[Category:How to Contribute]]

Latest revision as of 11:45, 24 August 2010

The Technology PMC is developing a new set of guidelines: Community_Development_for_Eclipse_Projects

The existing (or older) 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 [3], 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.

This page is moderated by the EMO