You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Working draft ... in progress.

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:

  • Code: open, discoverable, fully public history, documented provenance
  • Quality: security, backwards compatibility, etc
  • Contributions: welcome from anyone based on technical quality
  • License: Apache License, dependencies must not put additional restrictions
  • Community: inclusive, meritocratic, no dictators, clear documented path to entry
  • Discussions and decisions: asynchronous, in a single central place, archived
  • Decision making: consensus, votes if needed, technical vetoes in the worst case
  • Independence: from any corporate or organizational influence
  • Releases: source code only, notices, long-lived release format

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

 

  • CD10: The project produces Open Source software, for distribution to the public at no charge. [1]
    • Apache Taverna ...
  • CD20: The project's code is easily discoverable and publicly accessible.
    • Apache Taverna ...
  • CD30: The code can be built in a reproducible way using widely available standard tools.
    • Apache Tavera ...
  • CD40: The full history of the project's code is available via a source code control system, in a way that allows any released version to be recreated.
    • Apache Taverna ...
  • CD50: The provenance of each line of code is established via the source code control system, in a reliable way based on strong authentication of the committer. When third-party contributions are committed, commit messages provide reliable information about the code provenance. [2]

 

    • Apache Taverna ...

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.

 

  • No labels