CONTRIBUTING.md

Contributing to the SSI Generative AI Risk Register

Thank you for contributing to this register. This document explains how to propose new risks, suggest updates to existing risks, suggest resources, take part in discussion, and how contributions are reviewed.

Who can contribute?

Anyone is welcome to contribute. You do not need to be a member of the SSI to suggest a risk.

Contributions can be made either:

• publicly through GitHub Issues, or
• privately through a Microsoft Form if you do not have a GitHub account or would prefer not to post publicly.

Contribution routes

1. Propose a new risk (GitHub)

To propose a new risk publicly through GitHub:

1. Go to the Issues tab.
2. Click New Issue.
3. Select Propose a new risk.
4. Fill in the form, including any tags that apply to the risk.
5. Submit the issue.

GitHub Issues are the main public discussion route for the register. This means that, after submission, other contributors and maintainers can comment on the issue to ask for clarification, suggest refinements, discuss severity or likelihood, or propose related examples and mitigations.

In most cases, your proposal will be turned into a pull request or added to the register through the repository workflow, then reviewed by maintainers before being merged.

2. Propose an update to an existing risk (GitHub)

To suggest a change to an existing risk:

1. Go to the Issues tab.
2. Click New Issue.
3. Select Update an existing risk.
4. Fill in the form, including the issue number or identifier of the risk you want to update.
5. Submit the issue.

This route is useful if you want to:

• revise the wording of an existing risk;
• suggest a change to likelihood, severity, or reach;
• add or improve mitigations;
• add examples or evidence;
• link the risk to overlapping entries;
• suggest improved tagging.

As with new risks, update proposals can be discussed publicly through issue comments before being incorporated into the register.

3. Submit a risk privately or anonymously

If you do not have a GitHub account, or if you would prefer not to post publicly, you can submit a risk via this Microsoft Form.

This route is particularly intended for contributors who:

• do not use GitHub;
• would like to contribute anonymously;
• are raising risks that are specific to their project, institution, or working context and do not want those details attached to a public profile.

Private submissions are reviewed by maintainers and may be:

• added to the register directly;
• used to update an existing risk; or
• anonymised and posted by maintainers as a public GitHub issue so that the risk can still benefit from community discussion.

Anonymous or private submissions may be lightly edited by maintainers for:

• clarity;
• consistency of style;
• tagging;
• removal of identifying details; and
• generalisation of sensitive context where necessary.

The aim of this route is to support private submission without losing the benefits of public community discussion wherever possible.

4. Propose a new resource (GitHub)

To suggest a policy, position paper, guidance document, case study, report, or related resource:

1. Go to the Issues tab.
2. Click New Issue.
3. Select Propose a new resource.
4. Fill in the form, including a stable link and a short note explaining why the resource is relevant.
5. Submit the issue.

In most cases, resource proposals are turned into a pull request that adds a link and short notes to resources/README.md. During workshop facilitation, maintainers may enable workshop auto-publishing so new resource issues are added directly to the default branch.

5. Discuss a risk

Discussion is an important part of this project.

If you want to discuss a proposed or existing risk before making a formal proposal, you can:

• comment on an existing issue; or
• open a blank issue if you want to start a broader discussion.

Discussion can be used to:

• ask for clarification;
• challenge or refine a risk description;
• suggest alternative interpretations;
• debate severity, likelihood, or reach;
• propose mitigations or examples.

What makes a useful contribution?

Useful contributions are usually:

• specific — they describe a recognisable risk in research software practice;
• practical — they explain what could go wrong, who might be affected, and why it matters;
• grounded — they are based on experience, observation, or plausible emerging practice;
• actionable — they include mitigations, owners, examples, or references where possible.

Concrete, practice-based submissions are especially valuable. You do not need to fill in every optional field for a contribution to be helpful.

Good first contributions include:

• proposing a missing risk;
• clarifying the wording of an existing risk;
• suggesting a mitigation;
• adding an example or supporting reference;
• proposing a better tag; or
• commenting on an issue to refine an existing entry.

Review and editorial process

All contributions are reviewed by the Responsible AI Study Group before being added to the register.

During review, maintainers may:

• ask for clarification through issue comments;
• suggest amendments;
• merge overlapping submissions;
• normalise wording and tags;
• generalise overly specific wording;
• synthesise multiple related submissions into a single register entry.

Where multiple submissions are combined, maintainers may record the editorial decision in the register’s Maintainer Notes field to preserve provenance and explain how the entry was derived.

Private or anonymous submissions may also be incorporated into this editorial process.

Maintainers

• Joseph Shingleton
• Philipp Boersch-Supan
• Batool Almarzouq
• Oscar Seip
• Sangetta Bhatia

Code of Conduct

Please be respectful and constructive in all contributions. This register is a collaborative resource for the RSE community.

Please do not include personally identifying information, confidential project information, or institutionally sensitive details in public contributions. If your submission involves sensitive context, consider using the private submission route instead.