UPDATE: The Board found the pTLP concept to be without practical purpose and decline to entertain it. The option of going straight to TLP is open.

1. Introduction

Provisional TLP (pTLP) is one of the two currently available programs for bringing new projects into ASF (the first one being long-established ASF Incubation process). pTLP exists in parallel with an ASF Incubator and is NOT dependent on any of the policies established there. The two programs are complimentary, although it will not come as a surprise to see the same group of people involved in both. Neither process is expected to replace the other in the near term future. It is expected that new communities seeking to join ASF will be given pTLP as one of the options and they can pick either pTLP or a traditional Incubation route. It is also expected that some existing poddlings may wish to opt out for pTLP model even if they have been undergoing incubation for some time. The benefit of the pTLP vs. traditional incubation is primarily around a much tighter mentorship model with mentors being direct participants of the project. In fact, with pTLP the initial PMC is comprised of ASF Members who are performing the traditional mentorship role. It is expected that making mentors directly accountable to the project community will allow for faster Incubation time and a much more direct control over the trajectory that projects take within ASF.

2. About this document

This document is the normative reference for the policies and procedures that collectively define pTLP process. Apache Board members and PMC members of the pTLP projects are expected to understand and abide by the policies defined in this document. This document contains the minimum requirements that all new products and projects must meet before they will be fully accepted as a pTLP. 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 .

2.1. Scope

This document contains the minimum requirements and processes that must be met by products and projects wishing to become part of the Apache Software Foundation via the pTLP route. This document does not apply outside the process of pTLP and is completely independent from the policies defining ASF Incubation process. Policies and processes that need to be met by products under pTLP are not mandated (by this document) for other projects and sub-projects within the ASF.

2.2. Relationship to Other Documents

This document is the normative set of requirements for pTLP. The policy defined in this document leverages the TLP governance model as defined in this normative document. All of the policy clauses specific to the pTLP are called out explicitly in this document. In general, where other documents are in conflict, this document should be taken as correct.

3. Changing this Document

Currently this document is considered to be work in progress maintained as part submitting the very first pTLP resolution. Once the board approves the first pTLP resolution and thus adopts the definition of a pTLP as defined in this document on that day, it will implicitly create version 1.0 of the policy. All future changes to this policy document will require creating a different version and MAY be triggered by any existing ASF member as part of working on current or proposed pTLP resolutions.

4. Objectives of the Process

To provide a clear path for potential projects and sub-projects within the ASF to move from proposal stage through to fully membership in such as way as to ensure :

  • new projects and sub-projects are developing products according to the ASF's philosophy and guidelines for collaborative development;
  • the ownership of any code initially submitted by the project is formally and legaly transferred to the ASF; and
  • only those products that meet the Apache's requirements are fully accepted into the ASF.

5. Overview of the Process

The pTLP process covers the establishment of a candidate, acceptance (or rejection) of a candidate via a board resolution, and an ultimate step of a second board resolution that removes a provisional prefix leading to the establishment or a new Apache Top-Level-Project (TLP) or sub-project within an existing Apache Project. The day-to-day operation and governance of the pTLP project is expected to match very closely the TLP governance model as defined in this normative document. Where it differs, the pTLP process, as defined in this document takes precedent over the TLP policies.

6. Establishing a candidate pTLP project

In order for a project to join ASF as a pTLP project a candidate MUST:

  • be nominated by an ASF member, who will later serve as a pTLP Chair
  • has a proposed initial pTLP PMC composition that includes at least 3 ASF members
  • be approved by the ASF board via standard means of an ASF board resolution

While the pTLP process is completely independent from an Incubation process, it is highly desirable to keep IPMC aware of the projects seeking a pTLP route. Thus it is RECOMMENDED that as part of establishing the pTLP there is a notification submitted to the IPMC general mailing list. At that point it is up to the IPMC members to follow up with the candidate pTLP project.

6.1. Creating a pTLP proposal

The first step of establishing a candidate as a pTLP project MUST be creation of a pTLP proposal that clearly documents the following:

  • desired name(s) for the project
  • nature and goals of the project
  • current status of the project
  • details on how project has been developed and governed so far
  • list of existing contributors to the project
  • current IP ownership
  • list of external dependencies (both source and binary level)
  • list of know risks that the existing community would anticipate around project entering ASF
  • proposed list of PMC members for the project (with their corporate affiliations). The list MUST include at least 3 ASF members.
  • proposed Chair of the PMC (referred to as pChair in the rest of this document). The person MUST be an ASF member
  • proposed list of initial committers on the project (with their corporate affiliations).

In order to facilitate the consensus building process, the proposal MAY decide to clearly document the following:

  • location of the existing source code repository
  • location of the existing issue tracking system
  • location of the existing documentation
  • location and nature of any auxiliary infrastructure that the project MAY wish to request from ASF infrastructure team

Once the pTLP proposal is created it MUST be made public by initiating a \[DISCUSS] thread on general Incubator mailing list. The person initiating the thread MUST be pChair. That same person MUST actively solicit feedback on the proposal for no less than 10 days. Solicitation of feedback may include, but is not limited to:

  • giving ASF board members and explicit heads up
  • trying to reach out to corporate and individual past contributors to make sure that the list of proposed committers and the proposed composition of the PMC is a complete as possible

Once the proposal has been out in public view for no less than 10 days and the pChair feels that the expected level of consensus has been reached the proposal MUST be submitted to be voted by the ASF board via traditional means of the board resolution. From that point on pChair becomes the primary means of board communication with the pTLP and addressing any of the board concerns.

7. pTLP activities

After the board passes the resolution submitted by the pChair on behalf of the pTLP's PMC, the project is considered to be accepted as a pTLP project. From that point on it MUST go through the set of pTLP activities outlined in this section. The project is also required to report back to the board on a monthly schedule for the first three month and later transitioning to a typically quarterly reporting schedule. All communication with ASF board MUST be managed by the PMC Chair.

7.1. pTLP on-boarding activities

Once a pTLP resolution is approved by the ASF board it is expected that the 3 ASF members from the initial PMC MUST collectively make sure that:

  • all initial committers on the project go through a new committers on-boarding process as defined here
  • for existing code bases, a transfer of IP rights occurs via filing of the SGA
  • a source code repository gets established on ASF infrastructure
  • an issue tracking system gets established on the ASF infrastructure
  • a project public mailing list gets established on ASF infrastructure
  • a PMC-specific private mailing list gets established on ASF infrastructure

Once the initial on-boarding is complete, committers of the newly established pTLP MAY decide to:

  • transfer existing code base into the project source code repository
  • transfer existing issues into the project issue tracking system
  • request creation of auxiliary infrastructure (wiki, builds, etc.) from the ASF INFRA

The pTLP project SHOULD aim at finalizing on-boarding activities within three month.

7.2. pTLP steady-state activities

Once the pTLP on-boarding activities are complete, the project MUST enter its steady-state. In a steady state the project MUST be governed in accordance to  the TLP governance model as defined in this normative document and MUST be subject to all the policies defined in that document, expect for the pTLP specific policies summarized in the following list:

  • pTLP project MUST maintain a PMC that consists of at least 3 ASF members at all times. Failure to do so may result in project retirement.
  • pTLP project MUST have a Chair who is an ASF member
  • pTLP project MUST clearly label itself as Provisional and thus not yet endorsed by the ASF.
  • provisional designation MUST apply to:
    • source release artifacts
    • convenience binary artifacts
    • website and documentation available on-line
  • every release of pTLP project MUST have at least 3 +1s from ASF members on its PMC
  • every change to the pTLP PMC composition MUST have at least 3 +1s from ASF members on the PMC

7.3. Continuation

A pTLP project MUST continue functioning as defined in this document, until one of the following three events happen:

  • a pTLP PMC submits, and the board approves a resolution to promote the project to the full TLP status
  • a pTLP PMC submits a resolution to retire a project
  • an ASF board takes an explicit action that changes the status of the pTLP project

If any of these three events happen the project MUST transition into either one of the following states:

  • a full TLP status
  • a retired project

There are no other states for the pTLP project to be in. A retired pTLP project is subject to the TLP retirement policy.

8. Graduation to the full TLP status

Graduation to the full TLP status is the most desirable outcome for a pTLP project. pTLP's PMC MUST constantly monitor the progress of the project towards of the full TLP status by assessing its readiness based on:

  • the pTLP project behaves like a worthy and healthy project
  • the pTLP truly fits within the ASF framework; and
  • the pTLP's project community and most importantly its PMC gets "the Apache Way"

While some of the items listed above could have a degree of subjective measure and MAY be up for interpretation, the pTLP MUST at least meet the minimum requirements detailed below:

  • Legal

    • All code ASL'ed

    • The code base must contain only ASL or ASL-compatible dependencies

    • License grant complete

    • CLAs on file.

    • Check of project name for trademark issues

  • Meritocracy / Community

    • Demonstrate an active and diverse development community

    • The project 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)

    • The above implies that new committers are admitted according to ASF practices

    • ASF style voting has been adopted and is standard practice

    • Demonstrate ability to tolerate and resolve conflict within the community.

    • Release plans are developed and excuted in public by the community.

  • Infrastructure

    • SVN module or a git repository has been created

    • Mailing list(s) have been created

    • Mailing lists are being archived

    • Issue tracker has been created

    • Project website has been created and complies with the Apache Project Branding Requirements

    • Project ready to comply with ASF mirroring guidelines

    • Releases are PGP signed by a member of the community

    • Developers tied into ASF PGP web of trust

Once pTLP's PMC feels that the project complies with a minimum set of requirements AND with any additional requirements that PMC collectively feels make sense, the graduation process is triggered by a pTLP's PMC Chair submitting a resolution to the board requesting removal of the provisional status. The resolution MUST contain a final roster of the PMC and designated a Chair of the PMC.

9. Roles and responsibilities 

A pTLP policy specifically doesn't define any roles and responsibilities in addition to what is already defined in the TLP governance model, except for a proposed Chair. A proposed Chair MUST make sure that the pTLP proposal goes through all of the required steps of this policy and results as a resolution submitted to the board. Once the board votes on the proposal a proposed Chair either MUST be accepted as a Chair of the pTLP PMC or keep iterating on the proposal.

10. Appendix A: a pTLP checklist

While not part of the normative section of this document, the following checklist is a handy reference to what is expected when a project embarks on a pTLP journey:

  • Complete Name Search in accordance with Branding policy at http://www.apache.org/dev/project-namesearch

  • Check PMC Chair is recorded in LDAP.

  • Request Jira from INFRA

  • Request Mailing lists from INFRA

  • Add project to Reporting Schedule

  • Request source control (svn or git) from INFRA

  • Submission of ICLAs from existing committers.

  • Submission of CCLAs from affected companies

  • IP Clearance as described on http://incubator.apache.org/ip-clearance/

  • Filing of Software Grant, if applicable.

  • Change to Apache License v2.0, if applicable.

  • Update Apache Navigation to include project

  • Request User Accounts from INFRA

  • Request CMS from INFRA

  • Migrate existing documentation to Apache.

  • Ensure "Provisional" markings are adhered to, and link to http://....

  • Enable Notifications from Jira to Mailing list

  • Migrate existing codebase to Apache

  • Ensure dependency licensing compatibility, see http://www.apache.org/legal/resolved.html

  • Review legal compliance on all dependencies, in particular NOTICE file.

  • Ensure compliance with Branding policy

  • Establish self-assessed Apache Maturity Model declaration.

 

  • No labels