oneAPI_course/content/faq.md

Title: Apache Petri - FAQ source_button: yes

[TOC]

General

What is Apache Petri?

The Apache Petri (as in “petri dish” –where cultures are grown and bloom) committee assists external project communities interested in becoming an Apache project to learn how The Apache Software Foundation (ASF) works, its views on community, and how to build a healthy community for the long -term.

Petri’s mission is to mentor existing external communities (“cultures”) about “The Apache Way” by focusing on community governance that includes discussions about ASF policies. The mentoring and education is conducted on a mailing list.

The primary goal is to reach a point where a recommendation to the ASF Board can be made to construct a new Apache Project Management Committee (PMC) for the external community.

In the Incubator model, projects graduate to become Apache Top-Level Projects (TLPs). Under Petri, projects can become TLPs under a process described as “direct to TLP”, which is an alternative path to that used by the Apache Incubator. Apache Petri aims to shepherd projects and their communities to a point of confidence that the ASF Board will welcome the community to the Apache family of projects as a Top-Level Project.

How is Petri different from the Apache Incubator?

Apache Petri provides an alternative process to Incubation that would be suitable for some projects and their communities. Petri provides educational resources, and mentors external groups on their path to becoming an official project of the ASF. The primary goal is to reach a point where a recommendation to the ASF Board can be made to construct a PMC for the community.

“Podlings” in the Apache Incubator are provided a complete set of Foundation-based resources upon their acceptance into the Incubator. Since Petri will begin mentoring the community “where they live”, it will not provide an initial set of resources. Over time, as part of the education process and shift of the community towards the Foundation, resources will be provided as appropriate. It is expected that once a PMC is constructed, any resources not hosted at the Foundation will be the new PMC’s first order of business (i.e. a transition plan would be part of the presentation to the Board).

Why does this matter? What is special about The Apache Way? ¶

The Apache Way is the ASF’s process of community-led development is the backbone of all Apache projects, and emulated by many Open Source foundations. The Apache Way comprises:

• Earned Authority (merit);
• Community of Peers;
• Open Communications;
• Consensus Decision Making; and
• Responsible Oversight.

For more information, see The Apache Way.

The Apache Software Foundation's mission is to provide software for the public good.

Quoting from The Apache Way to Sustainable Open Source Success:

To allow us to deliver on this part of the mission, it is critical that we adopt a license that uses the law to protect the software curated here at the Foundation. For us that license is the Apache License, Version 2. In addition, we adopt an inbound licensing policy that defines which licenses are allowable on software reused within Apache projects. This policy can be summarized as:

• The license must meet the Open Source Definition (OSD).
• The license, as applied in practice, must not impose significant restrictions beyond those imposed by the Apache License 2.0.

What does “Direct to TLP” entail?

The Board makes the ultimate decision, and generally ensures that the project has:

• Demonstrated vendor neutrality in the community;
• Demonstrated understanding of the Apache Release Policy including Applying the Apache License;
• Completed Contributor Licence Agreements and Software Grant Agreements;
• Performed a Suitable Name Search;
• Developed a Transition Plan to move the project's resources to the ASF;
• Shown how the community will recognize merit; and
• Shown auditable decision making on the provided mailing list.

Is Apache Petri right for you?

If you are:

• An established, diverse community that already releases quickly; or
• A project with a single “leader” that seeks to grow to a community-driven development model; or
• A company that has an Open Source project with other vendors and wants to expand and diversify its community...

And you are:

• Willing to license your project's works under the Apache License, Version 2.

Petri would help the community learn how to integrate governance and development “The Apache Way” without interrupting the project’s velocity.

In keeping with the ASF’s slogan of “Community Over Code”, we are unable to accept projects that are not supported by some form of community.

Process

What about the Maturity Model? Have other projects bypassed incubation by meeting these requirements?

In March 2015 Apache Zest (now Polygene) became the first project to enter the ASF as a Top-Level Project — without entering the Apache Incubator. As part of the discussion, the project chose to review itself (private link) against the Apache Maturity Model, that addresses the integrity of a project's code, copyright, licenses, releases, community, consensus building, and independence, among other qualities.

The Apache Maturity Model will not be a requirement for communities (as the Model does not have broad consensus as a true and thorough viewpoint), but the Model may provide a helpful guide for some.

How long does the Petri process take?

There’s no “one size fits all” answer here. Some external projects have applied to the Apache Board to become TLPs, and have become TLPs without going through either Petri or the Incubator. Historically, every project’s experience and time spent in the Apache Incubator varies, depending on its specific needs and circumstances; this has ranged from less than one year to more than three years.

Similarly, some projects undergoing Petri mentorship will take longer than others. Petri is more about education about The Apache Way of project governance and Apache Policy, and less about process.

Do people involved in Petri-mentored projects need to sign ICLAs?

No, unless the projects intend to apply for TLP status and migrate their source control to ASF hardware. This applies both to Incubator podlings and direct-to-TLP applicants.

If our project wants to become an official Apache project, what is the best way to do so?

There is more than one way to do so: not all incoming projects will be mentored by Petri. Traditionally, the Apache Incubator has been the entry path for external projects, codebases, and communities wishing to become a part of the ASF.

Petri's primary goal is preparing a community for Direct-to-TLP; moving from Petri to become a podling undergoing development in the Apache Incubator is a possibility, but not mandated.

If I propose my project to be mentored by Petri, will it be accepted?

That depends. First, there have to be available mentors. Second, the Petri PMC may have to rate-limit intake, especially at first, in order not to stretch itself too thin with its oversight duties. This is true of the entire ASF: the Board may put intake of new TLPs on hold from time to time, though it has never yet done that to date.

What is the expected intake rate for Petri?

We anticipate 2-3 communities in the first year, with one per year likely following that.

What should the Board expect from a Project that Petri Recommends to become a TLP?

This list is only complete in that we are considering what the Board currently seems to require and it is as always up to the Board the requirements for any particular TLP. In addition to the list of items shared above, in the What does “Direct to TLP” entail section:

• Graduation Resolution. If there are Apache Members involved or recruited then they will be included in the resolution. Apache Members like anyone else are certainly invited to contribute to the project.
• Transfer of Registered Trademarks. If there are any registered trademarks then the transfer agreement will be discussed with the VP, Brand in advance.
• Software Grant. Petri should collect software grants.
• Committers. Petri can collect ICLAs in advance of going to TLP. Petri can make the committers from a prospective community Petri committers in order to create accounts.
• Resources. Graduation proposals will include a Transition Plan explaining the actions that the project has already taken or intends to take once the PMC is established. This may include:
  • Creating Apache project mailing lists
  • Creating Apache issue trackers
  • Creating Apache wikis
  • Creating Apache code repositories
  • Migrating code repositories to Apache
  • Applying the Apache License
  • Creating Apache web presence
  • Migrating web presence from Project to Apache
  • Rebranding web, code, documentation from Project to Apache Project
  • Retiring external Project and redirecting to Apache
  • Creating and migrating CI, build, release processes to Apache Project
  • Establish processes for release distribution at Apache
  • New TLPs should report on their progress towards completing their Transition Plan in their Board Reports.

Who will provide guidance once the Petri mentor is gone after the assessment?

This assumes that the Mentor is no longer interested in the community once it is assessed. Even if this were true TLPs have a range of Apache committees and resources available. If necessary the Board can provide additional guidance through the normal reporting process as the Board does for every PMC.

How can our project/community apply for Apache Petri mentorship?

Email discuss@petri.apache.org (public list; if you're not subscribe, ask explicitly to be Cc'd on replies) or private@petri.apache.org (private list, only Apache Petri PMC members and Apache Members can subscribe) and introduce yourself! We don’t have any forms or questionnaires, but may introduce these should the need arise.

If a project wants to move out of the Apache Incubator and into Petri, what happens?

We don’t recommend leaving the Incubator, if the podling is already established there; podlings should strive to graduate. In the event a community is unwilling to wait for graduation, and Petri has accepted them, then the Incubator will need to retire the podling. Petri will then take responsibility for the podling’s resources, and perform any needed changes to make that happen.