About developing standards

Developing an open standard can follow a variety of paths to the same goal: to produce a robust, successful and reusable shared agreement that helps produce better quality data.

This section, ‘Developing standards’, is intended as a guide to the activities, documents and resources to consider in developing a successful open standard.

This is not a set of rules to follow, but a guide to help you make the right choices for your open standard.

Review ‘How open standards are developed’ for an overview and ‘Creating open standards: Getting started’ to explore what to consider before developing an open standard.

Before you begin

In ‘Review’, we explore what to consider when assessing the impact of the open standard and what changes (if any) are needed for the standard to be effective, including doing nothing, updating the standard, and retirement.

With a consensus from the standard’s community on the next steps, the standard can be updated or actively retired.

Update the standard

Processes in the updates stage are similar to those in the ‘Development’ stage with some key differences. During development, the standard is new, so decisions focus on the features necessary for a robust and stable product.

At the ‘Review’ stage, the standard is in use, so changes will impact a wide variety of adopters – people and organisations using or supporting the standard, data produced using the standard, and models produced using guidance.

The impact of proposed changes should be carefully considered.

Adopters – including data publishers, data users, guidance users, and developers – may be affected in different ways. There may also be an impact on associated legislation, policy, products and services.

Changes to the standard may not affect on most adopters, but in some cases might require them to invest to incorporate the changes.

Typically, a major change is a departure from the current standard that introduces breaking changes, which means:

• existing tools based on the current version of a standard for data exchange or standard to share vocabulary may not work with the new version

• the structure of data produced using the new version of a standard for data exchange may be different from that using the current version

• new versions of standard to share vocabulary such as lists and ontologies may include significant, new or updated entries, classifications or hierarchies

• models produced using standards for guidance may vary between versions of the open standard.

While updating an open standard means investing in changes to the data infrastructure, when done right, these changes can make the standard easier to adopt and use.

It’s important to clearly communicate what the changes are and what impact they will have as early as possible. It should be clear to potential and existing adopters that changes have been made.

Versioning can make it easy to find and distinguish between changes to an open standard.

Versioning uses unique labels to track changes. The labels are usually an increasing number. Minor changes tend to be distinguished from major changes by a suffix for the minor and prefix for the major change.

For example, the first major release may be 1.0, a minor update 1.1, and a second major release 2.0.

Where multiple versions of the standard will be supported, each version may need:

• guides and resources that explain how to use the standard, including tutorials for learning, explanations to improve understanding, how-to guides for step-by-step problem-solving and references, which could be the standard in human-readable form

• translations of the open standard, guides and documentation and website content (if supporting multiple languages is necessary)

• test suites of data or models that both conform and break the standard to demonstrate scenarios adopters may encounter, handle or report

• tools for converting, validating and viewing data that uses the standard

• code libraries for processing or analysing the standard.

Typical activities when updating an open standard include:

• deciding on major or breaking changes – releases that could stop existing tools and services from working

• considering how many changes to include in the next version as it may be more acceptable to split a large volume of minor changes into separate updates

• gaining support from a variety of people and organisations in your community for the new version

• announcing changes in good time, allowing adopters to assess and plan for changes internally where needed

Once the scope and management of updates has been decided and agreed, work can begin on development of the new version.

Choose active retirement

‘Retirement’ – when a standard is no longer actively maintained – can happen for a number of reasons.

An open standard may be retired when:

• there is no longer funding to maintain the standard

• new standards or technology replace the standard

• changes in the landscape, including regulation, law, or practice, make the standard unnecessary

Following the Open Stand principles of working in the open, it’s important to keep the standard’s community informed if the standard is to be retired and no longer maintained. This is preferable to passive retirement, where the standard is no longer maintained and disappears without warning.

Typical ways to actively retire a standard include:

• circulating the decision within the community using available channels, for example social media, mailing lists, websites, forums or repositories like Github

• gifting intellectual property to the community or another organisation to continue the upkeep of the standard if necessary

• closing down websites and forums to prevent new updates but preserving the web presence – a notice may be added to inform visitors that the standard is no longer maintained

• archiving content using websites like Internet Archive, repositories like Github or other sites to maintain website information that will be lost once the domain is shut down.

Expected outputs

Typical outputs at the end of the update stage include:

• a list of changes shared with the community and used to guide the development process

• a stable version of the open standard in the form of a new minor or major version of the standard

• updated guides and documentation that explain what’s changed and how to use the standard