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.

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.

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

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.

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.