Probably the easiest way to adopt a governance model is to mildly adapt one that exists elsewhere. This is helped along by the fact that most such docs are themselves derivatives of other works from other groups or templates... This draft below is drawn
from a draft from another codeplex project and modified to take account of our needs, especially as listed by simon above. This remains a work in progress, but it captures some of what we need. Please give views on it.
.NET Bio Governance
September 10, 2013
Introduction and Guiding Principles
The central goal of the .NET Bio project is the provision of well engineered libraries and tools for bioinformatics on the .NET platform. While the focus of the library and the resulting tools may broaden over time, the initial vision lies in types and algorithms
supporting sequence analysis - both genomics and proteomics. Language interoperability is a crucial principle of the project, and we will in general seek to to develop and utilise managed code where possible, and to welcome contributions from a wide range
of supported languages. Our interests will include, but not be limited to: sequence analysis, pattern search and discovery, sequence alignment and assembly, common web services, interfacing to HPC and Cloud services, and visualisation. However, our focus remains
on computational tools for molecular biology, and the datasets and application areas provide a unifying framework for the project.
.NET Bio adopts the following guiding principles:
• Openness. Membership is open to all interested individuals who subscribe to our principles and governance structures.
• Community. The .NET Bio project is a public, community-driven body that develops via commitment and volunteer contributions of its members, supported by an overarching project leadership group - the Core Team.
• Transparency. No decisions about the project’s direction, bug fixes or features may be done without community involvement and participation, and these processes are as far as possible conducted on the public forums.
• 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. In the event that consensus is not reached in this time, active debate may be allowed to continue for a maximum of seven (7) days, after which the issue shall be resolved
via a vote of the core team.
The .NET Bio project is a community of participants actively involved in its efforts. Anyone with an interest in the project may participate by using the software and contributing to discussions, by improving documentation, by writing and executing unit tests,
by identifying bugs and contributing patches, or by developing new functionality and suggesting new directions for the project.
Roles and Responsibilities
The following roles can be assumed by members of the .NET Bio community.
Anyone who uses .NET Bio is a project user - so there are no criteria for membership of this group aside from an interest in the project.
Any user can share their views or ask for help on the forum, post bugs, propose features, contribute documentation, code, and tests. The .NET Bio User activities may include:
• 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
- contributing patches and new code
A Committer is someone with commit rights into the code repository. A Committer is in a position of power and responsibility - they therefore need to have demonstrated a commitment to the project and some level of technical knowledge so they don't damage the
repository, commit poorly-structured code or inappropriate contributions, such as incompatibly-licensed code or code submitted in violation of the provisions of its licence. A Committer is therefore a guardian of the quality of the project code (why we need
coding standards) and a supporter of the Vision for the project (why we need a vision statement).
A Committer should be appointed by a majority vote of the core team, and if accepted becomes a Core Team member.
The Core Team
Overarching leadership of the project is to be provided by the Core Team. The Core Team shall comprise:
- The overall list of active project committers
- Members of this project outside the list of committers whose expertise is valued by the project, with appointment through a simple majority of the Core Team.
The project leader is a member of the Core Team 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). Project leadership is here the responsibility of the Core Team, and a small subset of the Core Team may be authorised by simple majority to be listed as the project leadership for this purpose.
<appropriate CC licencing to be determined and listed here>