Outline completed 4/4/2016. Ready for content.

Goal: Make self-evaluation comments objective and demonstrable.

Overview

The purpose of this plan is to document the Apache Taverna podling's progress toward graduation from the Apache incubator. Initially, it is a roadmap for the Taverna PMC, showing completed items as well as those that have yet to be accomplished, and will help us focus our efforts to achieve project maturity. As graduation nears, the plan will be a measurable means for mentors, community members, the Incubator PMC, and the ASF Board of directors to assess Taverna's readiness to graduate. 

This Maturity Assessment Plan is based on the Apache Project Maturity Model and benefits from the experience of the Groovy Podling.

Status

 This is an initial outline of the Taverna Podling maturity plan and content needs to be added for each of the plan elements.

Assessment Summary

 When completed, this section will summarize the readiness of the Taverna podling to graduate.

Maturity Model Assessment

The Goals

A mature Apache project will meet the following goals:

These goals are from a January 6, 2015 message from Bertrand Delacretaz on the Apache community-dev mailing list. They provide a clear and concise introduction to the maturity model.

Assessment Categories

The Apache Project Maturity Model assesses whether or not a project complies with each element in the following seven categories: code, licenses and copyright, releases, quality, community, consensus building, and independence. There are no intermediate levels: a project either complies with an element or it does not. The following sections address Taverna's status regarding each element of the model.

NOTE: Numbers in brackets ([ ]) refer to footnotes on the Apache Project Maturity page, and are reproduced at the bottom of this document.

Code

Licenses and Copyright

Releases

Quality

Community

Consensus Building

Independence

Footnotes from Apache Project Maturity Model

[1] "For distribution to the public at no charge" is straight from the from the ASF Bylaws at http://apache.org/foundation/bylaws.html.
[2] See also LC40.
[3] It's ok for platforms (like a runtime used to execute our code) to have different licenses as long as they don't impose reciprocal licensing on what we are distributing.
[4] http://apache.org/legal/resolved.html has information about acceptable licenses for third-party dependencies 
[5] In Apache projects, the ASF owns the copyright for the collective work, i.e. the project's releases. Contributors retain copyright on their contributions but grant the ASF a perpetual copyright license for them. 
[6] See http://www.apache.org/dev/release.html for more info on Apache releases 
[7] The required level of security depends on the software's intended uses, of course. Expectations should be clearly documented. 
[8] Apache projects can just point to http://www.apache.org/security/ or use their own security contacts page, which should also point to that.
[9] In Apache projects, "consensus" means widespread agreement among people who have decision power. It does not necessarily mean "unanimity".
[10] For Apache projects, http://www.apache.org/foundation/voting.html defines the voting rules.
[11] Apache projects have a private mailing list that their PMC is expected to use only when really needed. The private list is typically used for discussions about people, for example to discuss and to vote on PMC candidates privately.
[12] Independence can be understood as basing the project's decisions on the open discussions that happen on the project's main communications channel, with no hidden agendas.