Incubator/Incubator Process

From Globus

This is the home for the Globus Incubator Process, which provides an entry path and guidance to Globus Incubator projects. This process is based heavily on the Apache Incubator policies and guidelines. Thanks to our friends at Apache.

Contents

Incubation Overview

The process for new projects to become part of Globus starts by that project becoming an Incubator project. This document describes the steps needed to move from a proposed candidate project completely outside of the Globus infrastructure, to an Incubator Project, one which is part of the Globus Incubator framework, which then develops into a full Project, and part of Globus. It describes the roles of the Incubation Management Project (IMP)-- the group which oversees the process associated with Incubator Projects, the Incubator Project Mentor -- a Globus Committer and member of the IMP who helps bridge between the new Incubator Project and Globus, and the review process -- including how to appeal decisions to the Globus Management Council (GMC) in case of disagreements.

About this Document

This document is the normative reference for the policies and procedures put in place by the Incubator Management Project for the Incubation process. It contains the minimum requirements that all new products and projects must meet before they will be fully accepted into Globus. This document does not apply outside the process of Incubation. Policies and processes that need to be met by products under incubation are not mandated (by this document) for other projects and sub-projects within Globus.

The document makes use of the terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL. Where capitalised, these terms are to be used as per the definitions found in RFC 2119.

This document is the normative set of requirements for Incubation. Where other documents are in conflict, this document should be taken as correct.

The contents of this document are formally approved by the Incubator Management Project. All changes must be authorised by the Incubator Management Project.

Roles in the Incubation Process

This section describes the roles involved in the Incubation process.

Incubator Management Project (IMP)

The Incubation Management Project(IMP) is the body that oversees new projects and products who wish to become part of Globus. A Candidate project is proposed, and when accepted by the IMP becomes an Incubator Project. This then undergoes periodic review until it becomes a Globus Project or is retired. The IMP is responsible for:

  • Providing oversight of Candidate projects submitted or proposed to become part of Globus;
  • Providing guidance and ensuring that Incubator Projects under it's purview develop products according to Globus philosophy and guidelines for collaborative development;
  • Providing a repository for the storage of incubation history and information;
  • Assisting a Incubator Project’s Mentor in discharging her/his duties;
  • Regularly (at least quarterly) evaluating projects under its purview for the purposes of recommending whether the project should:
    • Escalate project to a Globus project;
    • Continue to receive guidance and support as an Incubator Project; or
    • Retire and leave the incubation process.

They can be reached by email at incubator-committers@globus.org

Candidate Project

A Candidate Project is one which is proposed for incubation. A candidate project, when accepted by the Incubation Management project, becomes a Incubator Project.

Incubator Project

An Incubator Project, formerly called a ProtoProject, is a project following the incubation process. An Incubator Project, upon successfully completing the incubation process, becomes a Globus Project.

Mentor

A Mentor is a person who acts as a bridge between the Incubator Project and the Incubator process, specifically the IMP. This person is responsible for assisting the project to successfully complete the incubation process, for keeping the status information up to date, and for assistance in the quarterly reviews. A Mentor is initially suggested to the Incubator Project by the IMP, and must be a Globus Committer (someone who has Commit rights for a current Globus project). The Mentor becomes a member of the IMP if they are not already, and must have write access to the Incubator Project wiki.

Committers

Contributors who give frequent and valuable contributions to a project of Globus can have their status promoted to that of a “Committer” for that project. A Committer is a Contributor who has been given write access to the source code repository for that project and has a signed Contributor License Agreement (CLA) on file. A Committer gains voting rights allowing them to affect the future of the project.

Project Chair

Each Incubator Project is required to name a Project Chair via some process defined by the project’s Committers. A Project Chair has no enhanced authority, but has certain responsibilities relative to the function of the Group. Specifically:

  • The Chair MUST generate reports concerning the activities of the Incubator Project for the quarterly reviews
  • The Chair is responsible for forwarding to the Globus Infrastructure group requests to add or delete Committers for the project.

Incubation Process Overview

Objectives of the Process

The incubation process has been defined to provide a clear path for potential projects to move from Candidate stage through to Incubator Project and then on to full membership within Globus in such as way as to ensure:

Overview of the Process

The incubation process is how a potential project progress from submission (Candidate project) to full acceptance as a Globus project. In a nutshell, this process is as follows:

  1. A Candidate project is proposed to the Incubation Management Project (IMP)
    1. Candidate proposals have 7 pieces of information
  2. The IMP (and possibly the Globus Management Committee (GMC)
    1. Discuss the project
    2. Vote on its acceptability
    3. Accept the project, which now becomes a Incubator Project (previously called ProtoProject or Podling in Apache speak)
    4. Nominate a Mentor for the Incubator Project, a Globus committer who will act as a bridge between the IMP and the Incubator Project
    5. Assist the Incubator Project in the initial start-up steps for using the Globus CVS/SVN, wiki, bugzilla (for roadmap and bug tracking), licensing, and mailing lists
  3. The Incubator Project will undergo reviews, at least quarterly, which will have one of three outcomes
    1. The Incubator Project will remain in the Incubation state
    2. The Incubator Project will be asked to retire due to lack of progress
    3. The Incubator Project will “escalate” to become a full Globus project

This process is discussed in detail in the sections that follow.

Entry to Incubation

In order to become an Incubator Project, the following steps are followed.

Proposal

The first step to becoming an Incubator Project is for a group to propose themselves as a Candidate Project.

To start this process, a Candidate MUST submit a proposal to the IMP. The Proposal MUST, at minimum, detail the following areas :

  • A proposed name for the project;
  • The short preface for the mailing lists, if this project is acepted (*-dev, *-user, etc);
  • A proposed project chair, with contact information;
  • A list of the proposed committers for the project;
  • An overview of the aims of the project;
  • An overview of any current user base or user community, if applicable;
  • An overview of how the project relates to other parts of Globus;
  • A summary of why the project would enhance and benefit Globus;
  • A pointer to any current information (for example, an existing Web page) for the project

In general this proposal is less than 2 pages in length.

This information should be mailed to the IMP at incubator-committers@globus.org

Acceptance of Proposal by IMP

Upon receiving a Candidate project proposal, the Incubator Management Project (IMP) will discuss the appropriatness of the project for acceptance. The IMP performs filtering, not on the basis of technical issues, but on the likelihood of the project's becoming a successful meritocratic community. The decision to accept a project MUST be taken on a vote by the IMP, in accordance with their charter.

Upon acceptance by the IMP, the Candidate Project becomes a Incubator Project under the care of the IMP.

The IMP SHALL suggest a Mentor to the newly made Incubator Project. This person must already be a Globus committer, and will act as a bridge between the Incubator Project and the IMP. The Incubator Project MAY propose an alternative Mentor to the IMP. The IMP has the final choice of Mentors. The Mentor then becomes a member of the IMP and has write permission for the Incubator Project wiki.

The IMP MUST archive the following information :

  • A reference to the results of the vote (so as to provide an audit trail for the records);
  • A reference to the Candidate's proposal;
  • The name of the Mentor;
  • A reference to the acceptance notification.

A full checklist of actions by the IMP chair upon acceptance of a new project is listed here

Setting Up a New Incubator Project

Once the Incubator Project and Mentor have been accepted by the IMP, the following activities MUST take place:

  • Creation of standard mailing lists: *-dev, *-user, *-commit, and *-announce, where * is the name of the Incubator Project
  • Creation of CVS/SVN space in the GlobDev environment, to which the defined set of committers have access
  • Creation of the Wiki page, which much include a Status section as detailed below. Access will be granted to the set of committers and the Mentor.
  • Creation of a bugzilla project space, for error tracking and roadmap activities.
  • Pointers to the Globus licensing standards so that the Incubator Project can begin to work with them.

A sample Welcome Note is available as well.

Incubator Project Constraints

While in Incubation, Incubator Projects are constrained in the actions they can undertake.

Branding

Incubator Projects are, by definition, not yet fully accepted as part of Globus. Incubator Project Web sites MUST include a clear disclaimer and in all documentation stating that they are in incubation.

Incubator Projects MUST use the following text for all disclaimers :

<project name> is an effort undergoing incubation at Globus. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful Globus projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by Globus.

Incubator Projects wishing to use a different disclaimer message MUST have the disclaimer approved by the IMP prior to use.

Incubator Project websites SHOULD contain the Globus logo as sign of affiliation. The logo is located at http://www.globus.org/img/globusalliance-nourl.gif

www.globus.org/img/globusalliance-nourl.gif

Releases

As Incubator Projects are not yet fully accepted as part of Globus, any software releases (including code held in publicly available CVS/SVN) made by the Incubator Project will not be endorsed by Globus.

Infrastructure

An Incubator Project is not yet a Globus project, however the basic infrastructure on dev.globus.org is available for use, in particular

  • Each project will have a Wiki website on dev.globus.org
  • All project source resides in the project CVS/SVN, part of dev.globus.org
  • Every project will have an incubation status field on the Wiki
  • Every project will use the bugzilla for bug tracking and roadmap information
  • Every project will have 3 mailing lists set up it to use

The Mentors MUST add the information to the project incubation status file on the Wiki.

A full description of the infrastructure available to an Incubator is available here http://dev.globus.org/wiki/Incubator/InfrastructureRequirements

Incubation Activities

The following sections detail the minimum activities that must be undertaken by the various parties during an Incubation process.

Ongoing Activities

The progress of a Incubator Project SHALL be tracked in a "project status" field which SHALL be on the Incubator Project Wiki.

The "project status" document SHALL include the following minimum content :

The Mentor MUST ensure that the "project status" field is up to date at all times.

Review of Activity

Each Incubator Project in Incubation SHALL undergo a regular review of progress by the Incubator. Such reviews SHALL occur roughly quarterly. A sample review is available here. The IMP MAY, at their discretion, choose to review individual Incubator Projects with greater frequency. The IMP SHALL inform Incubator Projects of review dates at least 2 weeks in advance.

At least one week prior to each review, the Mentor MUST produce a report for the IMP detailing overall progress with a focus on the preceding review period. It is RECOMMENDED that the report be based on the "project status" document for the Incubator Project.

After each review, the IMP SHALL produce an Assessment of the project. The Assessment SHALL contain one of four recommendations:

  • that the Incubator Project be retired;
  • that the Incubator Project continue in Incubation;
  • that the Incubator Project begins Hibernation due to lack of forward progress over an extended period of time (usually a warning of no progress between 2 reviews, then hibernation at the next); or
  • that the Incubator Project be escalated out of the Incubator to Project status.

Disputing an Assessment

If the Incubator Project or Mentor disagree with an assessment, they MAY request the Incubator review the report. Such a request MUST include details of what the Incubator Project and/or Mentor is disputing, and their reasons for doing so. This MUST be done within two weeks of receiving the assessment.

Upon receipt of an Assessment Dispute, the IMP SHALL review the request and provide feedback to the Incubator Project and Mentor within two weeks. Such feedback MAY include a change to the original Assessment.

Should the Incubator Project and/or Mentor still disagree with the contents of the report, they may appeal to the GMC within two weeks. Such an appeal MUST include

  • the original assessment;
  • the request for review to the IMP;
  • the response from the IMP; and
  • the reason the Incubator Project and/or Mentor still dispute the report.

The GMC MAY, after reviewing the appeal, choose to

  • amend the incubation Assessment;
  • validate the assessment of the IMP; or
  • take any other action it deems appropriate to the circumstance.

The decision of the GMC will be produced within two weeks, and is final.


Assesment Results (Completing the Incubator Process)

After an assessment, a project may continue, be asked to hibernate, or complete. A Incubator Project can complete the Incubator process in two ways: it can escalate to become a full Globus Project or it can be retired.

Continuation

A recommendation by the IMP for continuation of incubation SHALL include development recommendations. The IMP SHALL ensure that the recommended actions are tangible and quantifiable.

The Mentor SHALL review the contents of the continuation recommendation and ensure that the development recommendations are carried out over the following review period.

Hibernation

A recommendation by the IMP for hibernation of incubation means that the IMP feels that the project is not making forward progress nor is likely to in the near future. When the IMP hibernates a project, it remains in the incubator state but is not reviewed or expected to make forward progress. The most common cause of hibernation is when the main funding source for a project is temporarily on hold or when the project lead is no longer involved for some reason and there is a management gap.

Often when no progress is made between two reviews, a warning will be given, and then if there is still no progress at the next review, hibernation will be recommended. When a project enters hibernation, the IMP will also list conditions for coming out of hibernation. These conditions and an end date for hibernation WILL be listed in bugzilla as part of the project tracking.

During the hibernation year, the project chair can contact the IMP or their mentor at any time during the year of hibernation and request to resume active status. The IMP will hold a vote to determine if the conditions to become an active project (as expressed in the initial entry to hibernation) have been met. This vote WILL be recorded in bugzilla as part of the project tracking, and the project will regain active status at that time.

At the end of the hibernation period, generally 12 months unless otherwise specified, the IMP will contact the former project and ask if it wishes to resume active status. If no reply is received or a commitment cannot be made the project will then be asked to retire.

Escalation to Full Project

Prior to escalation to a full Globus project, a Incubator Project needs to show that:

  • it is a worthy and healthy project;
  • it truly fits within the Globus framework; and
  • it "gets" the Globus Way.

This is achieved by imposing a set of Escalation Criteria that, when met, will demonstrate these objectives.

Therefore, to successfully complete the Incubator and be escalated fully into Globus, a Incubator Project SHALL meet the minimum escalation requirements detailed below. The IMP MAY set additional requirements at their discretion. Such additional requirements MAY be proposed by the Mentor or the Sponsor, however only the IMP is authorised to formally place such requirements on a Incubator Project.

In order to escalate, in most cases, it will become clear during the quarterly reviews that a project is ready. Alternatively, a project can request that their mentor initiate escalation consideration.

The mentor prepares an Escalation Review Report which lists and items for consideratoin in this case, and goes through the list of requirements, bullet by bullet, and states the readiness of the project. This is discussed and voited on by the IMP.

If the IMP accepts the case for esclation, the Escalation Review Report is ammended with the vote count of the IMP, and the IMP chair contacts the GMC for a vote on the matter.

If the GMC votes yes, then the project is escalated to full project (see Post Escalation Checklist below)

If either the IMP or the GMC vote to withhold escalation, the project is put into a continuation state.


Minimum Escalation Requirements

Sample Escalation Report

Description of using Infrastructure already in place in addition to dev.globus

The minimum requirements that a Incubator Project SHALL meet prior to being successfully escalated to a full product of Globus are:

  • Meritocracy / Community
    • Demonstrate an active and diverse development community. Preferably the list of original committers will have grown beyond the original set (and institution) in the proposal, but this is not a reqirement.;
    • Demonstrate that the project has a reasonable expectation for support in the future, for example, if any single contributor leaves the project continued support will exist;
    • The above implies that new committers are admitted according to Globus practices;
    • Globus-style voting has been adopted and is standard practice ;
    • Demonstrate ability to tolerate and resolve conflict within the community;
    • Release plans are developed and executed in public by the community;
      • At least 1 release has occurred during the Incubation process.
      • Note: Incubator Projects are not permitted to issue a Globus-sanctioned Release, as defined above.
    • Engagement by the incubated community with the other dev.globus.org communities;
  • Alignment / Synergy
    • Use of other Globus subprojects
    • Develop synergistic relationship with other Globus subprojects
  • Infrastructure
    • CVS/SVN module has been created on dev.globus.org
    • Three required mailing list(s) have been used
    • Issue tracker is being used (bugzilla)
    • Roadmap for project is present
    • Project website is current
    • http://dev.globus.org/wiki/Incubator/InfrastructureRequirements has a list of addition details with respect to infrastructure requirements


In cases where a Incubator Project has successfully completed Incubation, the IMP SHALL provide a recommendation to the GMC that the Incubator Project is ready to escalate. The recommendation SHALL include a draft resolution for the GMC to vote on.

Post-Escalation Check List

The list below summarizes steps a project needs to perform after escalation to move out of the Incubator space into the standard Globus project space.

  • Move wiki site
    • Chair requests infrastructure move old wiki to new Project wiki site
    • Chair requests infrastructure to update lefthand menubar
    • Chair requests infrastructure to redirect old incubator URL to the new one
    • Project verifies the redirect works, then deletes old stuff
    • Project updates wiki status field and header from "Currently Incubating" to "Successfully Incubated"
  • Project removes incubator disclaimer notices from CVS/SVN as needed


  • Upon approval by the IMP and the GMC, the archive must reflect
    • Final review report
    • Record of IMP vote
    • Record of GMC vote
    • Location of new project
  • Reporting
    • The Chair adds the new project to the GMC reporting schedule
    • The new project must send monthly GMC reports for three months after approval.

Retirement of a Incubator Project

If a Incubator Project receives a recommendation for retirement then problems with the Incubator Project have been identified by the IMP or Mentor. In most cases, there are either legal or structural problems with the Incubator Project that in the opinion of the IMP are not resolvable within a reasonable time frame. A retirement decision indicates that it is the opinion of the IMP that this project should be shut down until these issues can be addressed. A Incubator Project has the right to appeal a retirement decision with the GMC and/or the Sponsor, as described above.

Personal tools
Execution Projects
Information projects
Distribution Projects
Documentation Projects
Deprecated