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 ‘Scoping and starting’, we explore researching, planning and approving the goals, features, budget, schedule and resources to develop your open standard.

With an approved development plan and method selected, you can begin development.

The development method you selected will strongly influence how you develop the open standard.

In this section we focus on how you can develop your open standard collaboratively and in the open.

Assemble your team

In our research, ‘User experiences of open standard’, we found that developing a successful open standard means involving a wide variety of people and organisations.

Having contributions from people with different skills and backgrounds can bring constructive tension during the development of an open standard.

To create a successful open standard, consider involving:

researchers to continue research from scoping and starting, including how adopters find and use the standard and data produced using the standard
developers, data modellers and data experts to create the technical documents which will make up the standard, including schemas, specifications, models, and vocabularies
managers and others in positions of influence as early adopters and champions for the open standard
domain experts who understand the areas, sectors or industries the open standard will operate in, and provide expertise
business analysts to capture and reach consensus on the needs of representatives of the industry or sector
community engagement managers to keep in touch with the people and organisations involved with the open standard, data, or related products
project managers and product owners to coordinate and facilitate development
standards developing organisations to provide expertise in open standards development

It is important to ensure that everyone is clear on their role and responsibilities when developing a standard. We’ve identified and documented some key roles involved in developing a standard, including the chair, authors, testers and other contributors.

In the ‘Standards community’ section, we include organisation profiles of standards developing organisations. The ISO shares lists of nationally or internationally recognised formal standards bodies who may be able to support your standards development.

Set up your infrastructure

In ‘Scoping and starting’, we recommend choosing a development infrastructure to support the development team and share progress with the standards community.

For the development infrastructure, consider a repository or platform that:

allows public sharing of the open standard so you are developing in the open
allows public sharing of test data or test models
supports automated testing where needed
tracks changes so you have an audit trail and can remove changes if needed
supports contributions from a variety of people so you can accept community contributions or fixes if needed

Your development infrastructure should also include tools and platforms that:

support creating guides, resources and other documentation in the open
allow participants to report bugs or issues in the open
help you keep in touch with your community during development
make it easy to find, use and share data developed to test the standard

It is useful to consult your development team or the owner of the standard as they may have preferences for tools and platforms.

Develop the standard

With your team assembled and development method and infrastructure in place, you can start developing youropen standard.

Depending on the type of open standard being developed, this can mean drafting guidance, creating a dataset of shared vocabularies, or creating a format for data exchange.

As open standards can be mixed and matched, your open standard may use features from each of these types to achieve the intended impact.

For example, development may involve turning conceptual models (described in ‘Scoping and starting’) into technical documents like specifications, schemas, and models.

Other ways of turning the identified problem or need into a reusable agreement include:

agreeing and clearly defining words that will be uses in standards containing shared vocabularies
creating user stories (short, simple descriptions of features) when using an agile method
drafting documents using rules from a formal standards organisation — for example, the BSI’s rules for the structure and drafting of UK standards
designing standards to exchange data using vocabularies like JSON schema, XML schema, or database schemas

Test the standard

In our research, ‘User experiences of open standard’, we found that a successful open standard is one that has been tested and implemented.

In ‘Scoping and starting’, we recommend making testing part of the development plan.

Testing helps make your open standard more robust, which can improve trust and confidence and result in increased adoption rates.

Regardless of the development method, testing should be regular and rigorous.

Testing should cover:

the open standard
data produced using the standard
tools produced to support adopters, including developers, data publishers, and data users
resources like code libraries and websites that are used with the standard
integration with other standards – for example, where vocabularies are reused
a variety of likely scenarios adopters could encounter in real-world situations

Where possible, automate testing and share test models with the standards community for review and feedback. If early adopters are implementing pre-launch versions of the standard, they may be able to provide useful scenarios for testing.

Create guides and resources

Open standards are often technical documents specific to a particular technology or area of expertise.

To make standards easier to find, adopt and use, you can create guides and resources for different audiences.

An open standard for data will affect more than data users and data publishers.

Your audience may include people and organisations involved in policy, legislation, technology and more. Read ‘Creating impact with open standards’ to understand who open standards affect.

When creating guides, consider who will use them, the language you use needs of the potential user.

It’s useful to ask:

How do we communicate the standard to each group?
Which metaphors are useful in explaining complex concepts?
How will each group find and use the standard and guides?
Do documents need to be translated into other languages?
Should documents be available as hard copy, online, in accessible formats?

Recognise that open standards have a varied audience and aim to provide additional support through guides and resources to support adoption. For a different perspective, encourage early adopters to share their experiences with others.

Progress and activity should be shared regularly with stakeholders.

These are the people and organisations who will use or be affected by your open standard, data produced using the standard, or related products and services.

Sharing your progress may involve:

working in the open to keep in touch with your community
regular contact between participants to focus on important issues
tracking issues by collecting comments and resolving issues
producing regular drafts that can be reviewed by the community
clearly communicating milestones to provide opportunities for feedback
sharing test resources such as plans, test data, or test results for review

You can share progress online or offline depending on the needs of your stakeholders.

This may mean using repositories like GitHub, online reports, paper reports, noticeboards, and in person at workshops or other events. Progress updates can be shared at fixed stages or throughout the development process.

Expected outputs

Typical outputs at the end of the development stage include:

working versions of the open standard in the form of stable machine and human-readable versions of the standard
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 will encounter, handle or report
tools for converting, validating and viewing data that uses the standard
code libraries for processing or analysing the standard
early adopter experiences which can provide guidance to other stakeholders and feedback for the review stage
development infrastructure for the development team to develop the standard and share progress

Useful tools

Review the BSI’s principles of standardisation method to understand how a formal process works
See how Open Knowledge International uses an agile process: ‘Picking/designing a methodology’