Governance Models (Finally)

Coordinator
Aug 18, 2013 at 12:01 PM
For some time now I have been looking for bandwidth to initiate some discussion of governance for the .NET Bio project. Our project is starting to grow and people are becoming interested and active, and the more this happens the better. But one aspect of our affiliation with the Outercurve Foundation is the need to adopt an overall governance framework for the project. In the past the project has operated under the overall guidance of a technical advisory board or TAB, with roles at the follower, member and co-ordinator levels.

While the present structure has served reasonably well, we don't really have a clear process for transitions between these levels, and we have only a governance document for the TAB. I would like to initiate a discussion of these issues, with a view to adopting a governance document within a month or two.

To orient the discussion, it might be helpful to consider the document here from Ross Gardler and his colleagues. Ross has given us a good deal of guidance in the past, and the discussion here of the various governance models is I think very useful background.

The one that seems to sit closest to where we are currently, and in my view, best suits us, is probably the meritocracy model with some adaptations of naming and some specific rules as needed.

For now, I would like to propose a discussion period until the end of September, with some consensus and/or voting on a model to follow during October.

I would welcome both comments, and volunteers to share the work.

Best
jh
Coordinator
Aug 19, 2013 at 3:36 PM
Hi Jim,

I think you are right -- .NET Bio is probably now at a place where an official governance model would be helpful. I don't think we have a dictator (maybe Rick :-) in place so the meritocracy model is probably best. I'd be willing to help however necessary to set it up with you.

mark


Aug 19, 2013 at 3:58 PM
Thanks for getting this discussion started James,
I too have been trying to find the bandwidth to start this conversation.
In addition to the document James already linked to there is a blog post on the Outercurve site at [1] which is largely an updated version. There is also a discussion of the strengths and weaknesses of the meritocratic model [2] and the benevolent dictator mordel [3].
Finally, Eric Schulz also adapted my original template models for Outercurve Foundation projects [4]
I'd be very happy to share my experiences with various models if that helps the team understand the implications of their chosen model. I'm monitoring this thread and will chip in if I see a need.
My first recommendation is to keep it simple. Go for the minimum set of rules and processes possible, as long as your model has a process for resolving conflict it is good enough to get started. The goal is to reassure third parties thinking about contributing that they can get out more than they put in. Generally the more flexible the project is the more likely third parties will see what they need to see.
Ross

Ross Gardler (@rgardler)
Senior Technology Evangelist
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation



Coordinator
Aug 23, 2013 at 6:15 PM
Oddly enough, I have just been working with an academic on Meritocracy-based governance for another open source project. My personal inclination is to create a comprehensive document covering all eventualities, but these are long and boring - and in a world of volunteers on a project like this, that means they get ignored.

Somewhat saner heads than mine are prevailing in this other project and I am finding that simple an be good after all, so I'll propose the following framework based on that experience:

Vision Statement:
This should be a few lines saying what the project is for and what it covers. It needs to be broad enough to cover the interests of participants, but needs to also define what we are not here to do - so there are grounds to reject ideas and keep the project focused. We all agree this is about computational biology and not about IT infrastructure for example - so proteomics tools would be valuable but a new mailserver implementation might be a better fit for another project.

Coding standards:
We need (and in fact have) documented standards for what the source code should look like. These are needed so that the code remains readable and maintainable after code has been contributed from many different community members. Standards should include the need for unit tests with any patch.

Core team (="Leadership"):
  • I assume we would have a team of peers making decisions, including those on this thread
  • I assume we would default to making decisions by consensus, and that requires communication. I propose 'Lazy Consensus' (thanks to Eric Schultz for letting me know about that) - so if you want to propose a change to the project (e.g. a new feature), describe your idea publicly (post it here) and debate it constructively with anyone who has an opinion. If nobody objects within 72 hours of the post, we assume agreement and you should go ahead. Obviously debates can't go on forever, but if people are discussing actively at the end of the 72 hours then consensus may take longer- and that's okay.
  • We probably need a tiebreaker - so "in the event consensus cannot be reached, a decision is made by a majority vote of the core team"
Project users:
  • 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, etc.
Project Committers:
  • 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. Committing incompatibly-licensed code or the property of someone else would create a mess for all of us to clean up - and possible legal headaches.
  • 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.
How to contribute:
  • Use the forum to propose your code change (bug fix/feature request)
  • Listen to the feedback and strive for consensus
  • Read the documentation, download the code and implement your patch
  • Post to the forum when you are ready, and a Committer will review your code
  • The Committer may request changes if needed to meet the quality bar - once these are done, they will commit the code to the repository
This isn't complete but it is close - the core team membership isn't really defined, and I talk about a 'vote' but don't say how. Also, I say nothing here that explains how we manage access to this site for maintenance, how new releases happen, etc.

But it could be a start..... what do people think?

Simon
Coordinator
Sep 10, 2013 at 1:32 PM
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
Draft
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.

Member Participation

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.

User
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
Committers
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.
Project Leader
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>
Coordinator
Sep 10, 2013 at 1:36 PM
and yes, we need the contributor bullet points from simon and the link:

How to contribute:
Use the forum to propose your code change (bug fix/feature request)
Listen to the feedback and strive for consensus
Read the documentation, download the code and implement your patch
Post to the forum when you are ready, and a Committer will review your code
The Committer may request changes if needed to meet the quality bar - once these are done, they will commit the code to the repository

Contributors should view the coding standards and guides at: https://bio.codeplex.com/documentation
Developer
Sep 10, 2013 at 10:50 PM
Looks great, maybe though change the "computational tools for molecular biology" into "tools for biology"? I wouldn't mind having some phylogenetic/evolutionary biologist types feel included.
Coordinator
Sep 10, 2013 at 10:52 PM
Very timely feedback, thanks! I'll be working with Jim to finalize this today, hopefully.

Simon
Sep 12, 2013 at 3:16 AM
I recommend keeping as much contribution process as possible out of the governance document. The contribution process should be documented but the governance doc needs to be as light as possible. It can (in a project with many vested interests) be difficult to change whereas the contribution process needs to be agile to adapt to the changing requirements of the community.
People tend to pay lots of attention to changes to the governance but less to the development process. For this reason I generally try to limit the governance document to defining the roles and responsibilities each role has when managing the community. The development processes used on a day to day basis should be documented somewhere less permanent.
Add to this that most developers simpler don't care about the governance. They care about code. Governance matters to those investing in the developers. It's a different audience.
Ross

Ross Gardler (@rgardler)
Senior Technology Evangelist
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation



Coordinator
Sep 13, 2013 at 12:42 AM
Ross' feedback was also rather timely. So I will go ahead and propose that the text below be seen as our interim governance document, and open for comment until the end of September 2013, at which point it will, subject to revisions, become our official governance doc.

.NET Bio Interim Governance Document
September 13, 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 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. A simple majority will suffice to pass the resolution.
Member Participation

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. Information for participants, including guides for contribution, coding standards and a copy of this governance document and its successors, will be maintained at: https://bio.codeplex.com/documentation.

Roles and Responsibilities

The following roles can be assumed by members of the .NET Bio community.

User
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
Committers
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.
Project Leader
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>
Coordinator
Sep 13, 2013 at 2:37 PM

Sounds good to me…

Simon Mercer

Director, Health & Wellbeing | Microsoft Research Connections | Office +1 425-707-1441 | Cell +1 425-802-8213

Description: Description: Description: Description: cid:image002.png@01CBC7A7.6CBB9650

Coordinator
Sep 17, 2013 at 3:49 PM

It looks very good to me!

Jarek

Coordinator
Sep 17, 2013 at 4:01 PM
I also think it reads great.


Coordinator
Sep 21, 2013 at 1:14 AM
Thanks everyone. This has now gone to Outercurve, and we will place it on the site when we hear back from them, or sometime on or just after September 30, whichever is the soonest.

cheers
jh