DataSHIELD is developed as a collaborative, open-source project. Contributions are encouraged from across the community, ranging from small documentation changes and bug fixes to new functionality and longer-term collaborative developments.
Open development and communication
The DataSHIELD Social Contract emphasises that problems should not be hidden and that improvements should be shared with the wider free-software community.
Where possible:
bugs, feature requests and development discussions should take place through publicly accessible project infrastructure;
decisions affecting package behaviour or interfaces should be recorded so that their rationale can be understood by future contributors;
bug fixes and improvements to upstream dependencies should be communicated back to the relevant upstream projects; and contributors are encouraged to share experiences, ideas and reusable developments with the wider DataSHIELD community.
Disclosure-related issues are an important exception to fully public discussion. Potential disclosure vulnerabilities should be reported through the appropriate DataSHIELD risk-response disclosure-risk process so that the community can be informed without publishing information that could itself be misused.
Contribution workflow
Not every contribution will fit into a single issue or pull request. Larger developments may involve several contributors, multiple issues and pull requests, and development over an extended period. For these projects, contributors are encouraged to agree on the overall scope, responsibilities, development branches, milestones, and integration strategy at the start of the work. Individual components can then follow the contribution workflow above while remaining part of the wider development effort.
Repositories are encouraged to include a CONTRIBUTING.md describing any package-specific contribution arrangements. usethis::use_tidy_contributing() can be used to generate a starting template, which can then be adapted to the needs of the package.
DataSHIELD is committed to free and open-source software. Contributions should therefore be compatible with the licence of the repository and with the principles described in the DataSHIELD Community Free Software Guidelines.
By contributing to DataSHIELD, contributors confirm that:
Contributors submitting work created as part of employment, a funded project, consortium, or another organisation are encouraged to confirm that they have the necessary permission to contribute that work.
DataSHIELD is a collaborative project. Contributors are expected to DataSHIELD depends on participation from a diverse community of developers, researchers, data custodians, analysts and users. Contributions may include code, documentation, testing, bug reports, reviews, design discussions, examples, or sharing experience from real-world DataSHIELD implementations.
Contributors are encouraged to communicate respectfully, provide constructive feedback, make technical discussions accessible where possible, and help maintain a welcoming and inclusive development environment.
Contributions of different sizes are valuable. A small documentation correction, reproducible bug report, code review, or test can be as important to maintaining the project as a larger software development.
Contributions should be recognised in a way that reflects their nature and extent.
Possible approaches include:
The appropriate form of acknowledgement can be agreed between contributors and maintainers, particularly for larger developments involving several people or organisations.
A general template could include:.
---
name: 'Issue template.'
about: 'Use this template to report a bug or feature you would like to add to this
repo. '
title: 'Bug/Feature: Title of the issue'
labels: 'You can use labels such as “help wanted” and “good first issue” to help potential collaborators, including newbies, find your repo. See https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels'
assignees: ''
---
# If you are reporting a Bug:
**Describe the bug**
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
**Expected behavior**
A clear and concise description of what you expected to happen.
**Screenshots**
If applicable, add screenshots to help explain your problem.
**Please complete the following information:**
- OS: [e.g. iOS]
- R Version
- Relevant package versions (if applicable)
**Additional context**
Add any other context about the problem here.
# If you are requesting a new feature
**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
**Additional context**
Add any other context or screenshots about the feature request here.
Potential disclosure issues should therefore follow the DataSHIELD disclosure risk-response process rather than being treated as an ordinary public bug report.
A disclosure report can capture the following information:
# Disclosure Issue Report
## Summary
Provide a brief description of the potential disclosure issue.
> Example: A combination of DataSHIELD functions appears to allow recovery of information on an individual's UPRN.
---
## Reporter Information
* Name:
* Organisation:
* Email:
* Date Reported:
---
## Affected Component(s)
* Package(s):
* Function(s):
* Version(s):
* DataSHIELD Profile (if applicable):
* Server Platform (e.g. Opal version):
---
## Description of Potential Disclosure Issue
Describe the issue in detail.
Include:
* What behaviour was observed?
* Why might this lead to disclosure?
* Under what conditions does it occur?
* Is the issue reproducible?
---
## Potential Impact
Select all that apply:
* [ ] Information about an individual can be inferred
* [ ] Dataset reconstruction may be possible
* [ ] Circumvention of existing disclosure controls
* [ ] Other (please describe)
Provide further details on the potential impact.
---
## Steps to Reproduce
1.
2.
3.
Please provide a minimal reproducible example where possible.
---
## Evidence
Attach any relevant:
* Logs
* Screenshots
* Console output
* Example commands
* Proof-of-concept code
Please avoid sharing sensitive or real participant data.
---
## Severity Assessment
Reporter's assessment:
* [ ] Low
* [ ] Medium
* [ ] High
* [ ] Critical
Justification:
---
## Suggested Mitigation (Optional)
Describe any possible fixes or mitigations.
---
## Additional Context
Add any other information that may assist the Disclosure Response Team in assessing the issue.
---
- The guide appears to aimed at the process for small changes performed by a single person, when many of the changes are performed by a group of people and require colaboration over months.
Stuart - 2026-07-22