Draft Governance model for GitHub

[jim-smith]

No description provided.

[jim-smith]

Description of 'benevolent dictotor' model here on osswatch:

[jim-smith]

and this is datashield's original policy

copied from website here as. they are changing it:

Preface

While the below information is current, it is important to note that a new Governance Policy is under development by the DataSHIELD advisory board.

1. Overview

Ensuring that the DataSHIELD project is developed by the community in a structured and transparent way requires a certain degree of governance. This governance model has been adopted to strike a balance between encouraging anyone to make a contribution at any time and maintaining a high level of quality in the DataSHIELD software and its supporting resources. This governance model sets out:
The roles within the project’s community and the responsibilities associated with each role
How the project supports the community.
What contributions can be made to the project, how they are made, any conditions the contributions must conform to, who retains copyright of the contributions and the process followed by the project in accepting the contribution.
The decision-making process in within the project.
DataSHIELD is freely available under a GPL v3 licence.

2. Roles and responsibilities

There are a number of ways to participate in the project. Not all of them involve contributing source code. Simply participating on mailing lists, filing bug reports or enhancement requests, or even just forwarding a paragraph saying how DataSHIELD helped your work is an incredibly valuable form of participation.

There are five roles within the project’s community: users, adoptors, contributors, committers and the project lead (see project governance structure).

2.1. Users

Users are the people who download and use DataSHIELD or its related online resources, who have a need for DataSHIELD to do research. Without users, there is no reason for the project to exist. 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. Anyone can be a user.

Actions undertaken by users include:

Downloading and using DataSHIELD in their day-to-day research.
Letting the project know how DataSHIELD has helped them in their research (we have a list of papers on our website that we love to add to!).
Providing moral support – a ‘thank you’ goes a long way!
Offering letters of support for funding applications submitted by the project lead.
Asking for new features or enhancements to DataSHIELD or its related resources.
Reporting bugs in DataSHIELD or typos in its related resources.
Users who continue to engage with the project and its community will often find themselves becoming more and more involved. Such users may then go on to become contributors.

2.2. Adoptors

Adoptors are the groups who have made data available via DataSHIELD. They may be biobanks, hospitals, universities etc. There will be a group of users who wish to utilise the data made available by adoptors via DataSHIELD to do research

Setting up DataSHIELD locally.
Harmonising data with other data providers.
Helping users of their data.
Letting the project know how DataSHIELD has helped them in their research.
Providing moral support – a ‘thank you’ goes a long way!
Offering letters of support for funding applications submitted by the project lead.
Asking for new features or enhancements to DataSHIELD or its related resources.
Reporting bugs in DataSHIELD or typos in its related resources.

2.3. Contributors

Contributors are individuals who contribute to the project but either do not have write access to the project resources or have no desire to become committers. They make valuable contributions, such as those outlined below, and submit these through the project’s communication tools.

Anyone can become a contributor. There is no expectation of commitment to the project, no specific skill requirements and no selection process. To become a contributor, a community member simply has to perform one or more actions that are beneficial to the project.

Actions undertaken by contributors include:

Supporting new users as current users often provide the most effective support for new users.
Fixing bugs in DataSHIELD and typos in its related resources.
Implementing enhancements.
Implementing new features.
Implementing tests, whether these be automated tests or manual testing protocols.
Writing documentation e.g. FAQs, HOW-TOs, blog articles or case studies of DataSHIELD in use.
Assisting with project infrastructure.
As contributors gain experience and familiarity with the project, they may find that the project lead starts relying on them more and more. When this begins to happen, they may be invited to adopt the role of committer.

Contributions are reviewed by committers and integrated at their discretion. This is an iterative process. Feedback will be given should a contribution be rejected. Before code contributions can be added to the source code repository, a completed Contribution Licence Agreement (CLA) is required from the contributor or their organisation. See 4. Contributions Process below.

2.4. Committers

Committers are contributors who have made several valuable contributions to the project and are now relied upon to both write code directly to the project’s source code repository and validate and integrate the contributions of others. In many cases they are programmers but it is also possible that they contribute in a different role (for example, updating the web site or managing e-mail lists). Typically, a committer will focus on a specific aspect of the project, and will bring a level of expertise and understanding that earns them the respect of the community and the project lead. The role of committer is not an official one, it is simply a position that influential members of the community will find themselves in as the project lead looks to them for guidance and support.

Committers facilitate the overall management of the DataSHIELD project, ensure that releases are planned correctly and completed on schedule and decide who receives commit access to the source code repository, that is, who can become a committer. This ensures that the quality of the software and the associated documentation remains high and the conceptual integrity of the project is maintained.

Committers have no authority over the overall direction of the project. However, they do have the ear of the project lead. It is a committer’s job to ensure that the lead is aware of the community’s needs and collective objectives, and to help develop or elicit appropriate contributions to the project. Often, committers are given informal control over their specific areas of responsibility, and are assigned rights to directly modify certain areas of the source code. That is, although committers do not have explicit decision-making authority, they will often find that their actions are synonymous with the decisions made by the lead.

If invited to become a committer, or a request to become a committer is granted, a completed Contribution Licence Agreement (CLA) is required from the committer or their organisation. See 4. Contributions Process below.

2.5. DataSHIELD Leads

DataSHIELD leads hold established expertise in areas strategic for the evolutio of DataSHIELD.

DataSHIELD leads have no authority over the overall direction of the project. However, they do have the ear of the principal investigator. It is a committer’s job to ensure that the lead is aware of the community’s needs and collective objectives, and to help develop or elicit appropriate contributions to the project. Often, DataSHIELD Leads are given informal control over their specific areas of responsibility in the broader project development, although they do not have explicit decision-making authority, they will often find that their actions are synonymous with the decisions made by the principal investigator.

2.6. Principle Investigator (PI)

The PI is responsible for the overall direction and vision of the project.
The PI is a benevolent dictator – see 5. Decision-Making Process.

The project lead for DataSHIELD is Professor Paul Burton, one of the original designer and developers of DataSHIELD.

3. Support

All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community.
Those seeking support should recognise that all support activity within the project is voluntary and is therefore provided as and when time allows. A user requiring guaranteed response times or results should contact the project lead and discuss whether a support contact can be negotiated. However, for those willing to engage with the project on its own terms, and willing to help support other users, the project’s infrastructure is ideal.

4. Contribution Process

Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. There follows a summary of what contributions can be made, how they are made, any conditions the contributions must conform to, who retains copyright of the contributions and the process followed by the project in accepting the contribution.

4.1. Contributions

4.1.1. Discussions around DataSHIELD

How: E-mail, forum
Conditions: –
Copyright: –
Process: Just discuss!

4.1.2. Moral support or comments on how DataSHIELD has helped you

How: E-mail
Conditions: –
Copyright: –
Process:

We ask if we can quote you on the web-site
We thank you profusely
We optionally ask if you’d contribute a Case study (see below).

4.1.3. Feature request

How: Create issue on GitHub under the relevant repository.
Conditions: –
Copyright: –
Process:

You check that the feature has not already been requested
If you post in the forum, we’ll check that it doesn’t already exist and hasn’t been addressed already, and, if not, we’ll create an issue on GitHub and let you know either way
If you create an issue we’ll check that it doesn’t already exist and hasn’t been addressed already
If it does exist we’ll mark your issue as a duplicate
If it has been addressed already we’ll let you know

4.1.4. Feature implementation

How: GitHub pull request
Conditions:

You check that the feature has not already been implemented
Code confirms to coding standards
Code is available under GPL v3 open source licence
You are the author of the code, or have the author’s permission to contribute it and you are willing to complete a Contribution Licence Agreement
You provide a list of steps required to test your feature
You provide any changes or new user documentation that your feature needs
Copyright: You retain copyright of your code
Process:

We check the code conforms to coding standards and has a suitable licence
We merge your pull request into a local repository and check that the software still builds
We run though the list of steps to test your feature
We validate any documentation you provide
You complete a Contribution Licence Agreement
We add you as a co-author to the web site and other project resources

4.1.5. Enhancement request

How: As for Feature request
Conditions: –
Copyright: –
Process: As for Feature Request

4.1.6. Enhancement implementation

How: As for Feature implementation
Conditions: As for Feature implementation
Copyright: As for Feature implementation
Process: As for Feature implementation

4.1.7. Bug report

How: As for Feature request. Optionally, submit a pull request with a test, or a sample code fragment, demonstrating the bug.
Conditions: –
Copyright: –
Process: As for Bug report

4.1.8. Bug fix

How: As for Feature implementation
Conditions: As for Feature implementation
Copyright: As for Feature implementation
Process: As for Feature implementation

4.1.9. Documentation enhancements or corrections

How: As for Feature request.
Conditions: –
Copyright: –
Process:

We add you to our acknowledgements on the web-site
We check your proposed enhancements or corrections and apply these.

4.1.10. Tutorial / HOW-TO

How: As for Feature request
Conditions:

You are the author, or have the author’s permission to contribute it (in which case you should prove this)
Documentation confirms to a suitable open licence e.g. Creative Commons Attribution 3.0
Copyright: You retain copyright
Process:

We work through the tutorial and check it for readability and correctness.
We add you to our acknowledgements on the web-site, and your name to your tutorial’s web-page.
If there are issues, we’ll work with you to resolve these.

4.1.11. Case study

How: As for Tutorial
Conditions: As for Tutorial
Copyright: As for Tutorial
Process: As for Tutorial

4.1.12. Letters of support for funding applications submitted

How: E-mail project lead
Conditions: You’ve been invited to do so by the project lead
Copyright: You retain copyright
Process: –

4.2. Contributor Licence Agreement (CLA)

In order to accept any contribution of code we require that you first complete either an Individual or Corporate Contributor’s Agreement acknowledging certain terms and conditions for its use. Once this agreement has been completed and the code is accepted then it can be committed to the source code repository.

Two agreements are available to choose from depending on whether you represent an individual or a corporate contributor:

DataSHIELD-CLA-Individual.doc (forthcoming)
DataSHIELD-CLA-Corporate.doc (forthcoming)

5. Decision-Making Process

The project runs as a benevolent dictatorship. That is, the community actively contributes to the day-to-day maintenance of the project, but the general strategic line is drawn by the principal investigator. The principal investigator is the ultimate authority on decisions, and the principal investigator’s decisions are final. The principal investigator will, wherever possible, seek consensus on decisions from all committers and project leads and is open to reviewing decisions in light of changing circumstances.
The principal investigator will resolve disputes within the community and ensure that the project is able to progress in a coordinated way. In turn, it is the community’s job to guide the decisions of the principal investigator through active engagement and contribution.

For more on the benevolent dictatorship model.

About this document
This document is licenced under Creative Commons Attribution-ShareAlike 2.0 England & Wales licence

It is based upon a combination of elements from:

OSS Watch’s Benevolent dictator governance model. Copyright © 2007-2013 University of Oxford.
DataShiueld Original governance Model