DataSHIELD governance policy

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.

DataSHIELD code and documentation is copyright:
Copyright © 2013-2016 The University of Bristol

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 4 roles within the project’s community: users, contributors, committers and the project lead. The organisation structure of DataSHIELD.

2.1 Users

Users are the people who download and use DataSHIELD or its related online resources, who have a need for DataSHIELD. 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.
  • 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 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.

Current contributors include:
Dr Elinor Jones, UCL (statistical methodology)
Dr Julia Kutschke, Norwegian Institute of Public Health, Oslo (developer)
Dr Joel Minion, University of Bristol (social studies of science)
Dr Mintu Nath, University of Leicester (genetic statistics)
Dr Chris Nelson, University of Leicester (genetic statistics)
Dr Chris Newby, University of Leicester (statistical methodology)
Dr Anne Marie Tasse, McGill University (law)
Dr Jonathan Tedds, University of Leicester (health informatics)
Prof John Thompson, University of Leicester (statistical methodology)
Prof. Edwin Van den Heuvel, Eindhoven Uni of Tech (statistical methodology)
Dr Joshua Vande Hey, University of Leicester (geospatial)
Dr Susan Wallace, University of Leicester (law)

2.3 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.

Current committers including DataSHIELD responsibilities:
Dr Becca Wilson – DataSHIELD project management
Dr Andrew Turner – DataSHIELD code repository management
Vincent Feretti – Opal management
Yannick Marcon – Opal developer
Prof. Madeleine Murtagh – Governance
Dr Demetris Avraam – DataSHIELD developer
Tom Bishop – DataSHIELD developer
Dr Oliver Butters – Infrastructure

2.4 Project Lead

The project lead is responsible for the overall direction and vision of the project.
The project lead 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: Post in the DataSHIELD forum or email datashield-research@bristol.ac.uk
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: Post in the DataSHIELD forum or 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 to 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. The decision making and organisations structure of DataSHIELD.

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: