Trident governance model

Mar 20, 2013 at 2:31 AM
As an open source community, we're required to have a governance model. Below is a draft, please comment and suggest changes, updates and revisions (the draft is available as a doc file upon request). After a certain amount of time, we'll need to finalize this draft and post our governance model.

Trident Governance
Draft
March 15, 2013

Introduction and Guiding Principles

The goal of the Trident project is to assist users in automating tasks in experiment implementation or data analysis, management and preservation. This is achieved through the development and implementation of scientific workflows that become part of an integrated environment. The emphasis of Trident is on community involvement in the development and sharing of workflows as well as in the development of technical features for Trident system.

To effectively facilitate community involvement, Trident adopts the following guiding principles:

• Openness. Membership is open to all interested individuals who subscribe to Trident guiding principles and governing rules.
• Community. Trident is a public, community-driven body that develops via commitment and volunteer contributions of its members, supported by Trident Project Management Committee and by Trident Project Leader.
• Transparency. No decisions about the project’s direction, bug fixes or features may be done without community involvement and participation.
• Lazy Consensus. Lazy consensus is a process of reaching consensus with a minimal effort.
When a proposal is put forward, the default assumption is that the community already have consensus. Unless someone objects to the proposal, the work can begin. The proposals will have at least 72 hours before assuming that there are no objections. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal.

Member Participation

The body of Trident community consists of individual members who are actively involved in its efforts. Organizations may also engage in Trident community. Individual or organizational members participate through the discussion forum or by assuming one of the roles described below. A member of the community may have multiple roles.

Roles and Responsibilities

The following roles can be assumed by members of Trident community.

User
Users are community members who are interested in using the Trident system to support their needs. They are the most important members of the community: without them, the project would have no purpose. Anyone can be a user; there are no specific requirements.
Users are encouraged to participate in the life of the project and the community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user activities include (but are not limited to):

• advocating for use of the project
• informing developers of project strengths and weaknesses
• writing documentation and tutorials
• filing bug reports and feature requests
• participating on the discussion board

How to become one: Use Trident

Contributors
Contributors are community members who submit pieces of code and patches to the project. These contributions may be a one-time occurrence or occur over time. Contributors are encouraged to submit patches that are small at first and grow larger once the contributor has built confidence in the quality of their patches.
Before a contributor’s first patch is put into the repository they must sign a Contributor License Agreement (CLA). The patch can be submitted and discussed but it can’t actually be committed to the repository without a signed CLA.
How to become one: Submit a patch to the Trident project at http://tridentworkflow.codeplex.com/

Committers
Committers are contributors who have shown dedication to Trident, technical expertise and the ability to work well with contributors and users. The committers have responsibilities beyond contributing patches. In particular, committers formally decide on whether patches are entered into the main code repository and add those requests. Additionally, they verify with Outercurve Foundation staff that a potential contributor has a signed CLA before committing a patch to the repository. A committer will use lazy consensus (see below) to decide on whether to commit a patch from a contributor. If the discussion is no longer moving towards a consensus, the committer may use their best judgment on whether to commit the patch.
How to become one: Be a contributor and be nominated to the PMC as a committer. You may nominate yourself.

Project Management Committee (PMC)
The project management committee (PMC) participates in strategic planning, release planning, and approving changes to the governance model. It also makes decisions when community consensus cannot be reached.
The PMC has final say over who can become a committer and will use lazy consensus for approval. Discussion over committer nominations will be done in private.
Membership of the PMC is by invitation from the existing PMC members. A nomination will result in discussion and then a vote by the existing PMC members. PMC membership votes are subject to consensus approval of the current PMC members and will be done in private.
How to become one: Be invited by a current PMC member and have nomination approved by the PMC.

Project Leader
A project leader is a member of the PMC whom the Outercurve Foundation staff consider the primary point of contact or first point of contact for the project for purposes of business operations including domain registrations, and technical services (e.g. code-signing).
In the event there are multiple project leaders, Outercurve staff will consider a request by any single leader as sufficient for action.
How to become one: Have nomination approved by members of the PMC.

Voting

The Trident project realizes that not all decisions can be made using lazy consensus. Issues affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. Every member of the community is encouraged to express their opinions in all discussion and all votes.


_This document is licensed under the Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales license (CC BY-SA 2.0 UK, http://creativecommons.org/licenses/by-sa/2.0/uk/).
Free to distribute and make derivatives._
Mar 20, 2013 at 4:59 PM
This is very exciting! One thing to remember is that the CC license requires we cite the original source of the document which is "Meritocratic Governance Model" by University of Oxford.

I'd love to hear what other members of the community think. Any suggestions for improvements or changes?

Eric
May 31, 2013 at 3:26 AM
At CSIRO, we are actively pursuing the use of the Trident workflow tool towards better provenance capture. See http://www.csiro.au/Organisation-Structure/Flagships/Water-for-a-Healthy-Country-Flagship/Integrated-Water-Resources-Management/Hydrologists-workbench_CLW_Project.aspx.

We expect that this governance model will clarify the ways in which we can contribute to the development of the workflow tool.

Cheers,
Dave