Draft for splitting 'Welcome contributions'

We chose the axis equal/easy access vs. tooling to make collaboration viable. That lead us to split it into Welcome contributors and Make contributing easy. Things that are in a block quote are new additions. More new additions might be needed as well.

Welcome contributors

Requirements

The codebase MUST allow anyone to submit suggestions for changes to the codebase.

The codebase MUST include contribution guidelines explaining how contributors can get involved, for example in a CONTRIBUTING file.

The codebase SHOULD advertize the committed engagement of involved organizations in the development and maintenance.

The codebase SHOULD document the governance of the codebase, contributions and its community, for example in a GOVERNANCE file.

The codebase SHOULD have a publicly available roadmap.

The codebase MAY include a code of conduct for contributors.

Why this is important

  • Helps newcomers understand and trust your codebase community's leadership
  • Prevents the community that works on a project splitting because there is no way to influence codebase goals and progress - resulting in diverging communities.
  • Helps users decide to use one codebase over another.

What this does not do

  • Guarantee others will join the community.
  • Guarantee others will reuse the codebase.

How to test

  • It's possible to submit suggestions for changes to the codebase.
  • There are contribution guidelines.
  • Codebase governance is clearly explained, including how to influence codebase governance

Policy makers: what you need to do

  • Add a list to the codebase of any other resources that policy experts, non-governmental organizations and academics would find useful for understanding or reusing your policy.
  • Consider adding contact details so that other policy makers considering reuse can ask you for advice.

Management: what you need to do

  • Make sure the documentation explains how your organization is involved in the project, what resources it has available for it and for how long.
  • Support your experienced policy makers, developers and designers to stay part of the community for as long as possible.

Developers and designers: what you need to do

  • Respond promptly to requests.
  • Keep your management informed of the time and resources you require to support other contributors.

Further reading

Make contributing easy

Requirements

The codebase MUST have a public issue tracker that accepts suggestions from anyone.

The codebase MUST include an email address for security issues and responsible disclosure.

The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a README file.

The project MUST have communication channels for users and developers, for example email lists.

The documentation SHOULD include instructions for how to report potentially security sensitive issues on a closed channel.

Why this is important

  • Enables users to fix problems and add features to the shared codebase leading to better, more reliable and feature rich software.
  • Allows collaborative uptake of shared digital infrastructure.
  • Helps users decide to use one codebase over another.

What this does not do

  • Guarantee others will reuse the codebase.

How to test

  • There's a public issue tracker.
  • It's possible to participate in a discussion with other users about the software.

Policy makers: what you need to do

  • Track policy issues in the codebase, so that a relevant external policy expert can volunteer help.

Management: what you need to do

  • Track management issues in the codebase, so that external managers with relevant experience can volunteer help.
  • Support your experienced policy makers, developers and designers to keep contributing to the codebase for as long as possible.

Developers and designers: what you need to do

  • Respond promptly to requests.
  • Keep your management informed of the time and resources you require to support other contributors.

Further reading

Select a repo