Standard for Public Code

Readers guide

The criteria in the Standard have a consistent sections that together make it clear how to create great public code.

Requirements

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.

This helps:

  • 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 are usually less technologically experienced but often set the priorities and goals of projects.

Management: what you need to do

This section tries to specifically speak to management by offering them 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.

Further reading

Read more about why these requirements exist and how to make them work.