Development

This section unpacks the ‘development’ stage to open standard development, with focus on how you can work in the open with a wide community to create and test your open standard

Assemble your team

In our research, ‘User experiences of open standards’, 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.

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 your open 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 used 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 standards’, 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 must meet the needs of the potential users.

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.

Share your progress

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 Foundation uses an agile process: ‘Picking/designing a methodology’