The Standard describes a number of criteria. All criteria have consistent sections that make it clear how to create great public code. Below is a brief explanation of each of these sections and how they are used within the criteria of the Standard.
This section lists what needs to be done in order to comply with the standard.
In order to limit ambiguity, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in IETF RFC 2119.
Why this is important
This section explains why it is important for the users and contributors of this codebase that these requirements are followed.
What this does not do
This section manages expectation by explaining what following the requirements will not save you from.
- with applying the Standard correctly
- make sure no unexpected things pop up
How to test
This section offers actions you can take to see if a contribution is compliant with the Standard. This is key if you want to operationalize the Standard.
We’ve tried to word it so that someone who is not intimately acquainted with the subject matter can still do a basic check for compliance.
Policy makers: what you need to do
This section tries to specifically speak to policy makers by offering them concrete actions they can perform in their role.
Policy makers set the priorities and goals of projects and may be less technologically experienced.
Management: what you need to do
This section tries to specifically speak to management by offering concrete actions they can perform in their role.
Management is responsible for on-time project delivery, stakeholder management and continued delivery of the service. For this they are wholly reliant on both the policy makers as well as the developers and designers. They need to create the right culture, line up the right resources and provide the right structures to deliver great services.
Developers and designers: what you need to do
This section tries to specifically speak to developers and designers by offering them concrete actions they can perform in their role.
Developers are usually more technically aligned and have more impact on the delivery of services than the previous groups.
Read more about why these requirements exist and how to make them work.