Review
This section unpacks the ‘review’ stage of open standard development, focusing on how to assess and review an open standard and decide whether to leave it unchanged, update it, or retire it
Deciding to review
As your standard is adopted and used, errors, requests for changes and new features could emerge. The landscape around the standard may also change: new standards, regulations, and other changes could lead to the standard needing an update or retirement.
At the scoping and starting stage, the owner of the standard can decide when the standard will be reviewed. The review may be scheduled or triggered when certain conditions are met, for example:
a new policy or legislation is announced
a particular number of errors are discovered
a particular number of changes are requested
To build trust and confidence in the open standard, it’s useful to have clear guidance on how and when the review will happen. This guidance is part of the standard’s governance process.
When deciding to review, it’s useful to:
be explicit about the review schedule and include this in your standard’s governance process
decide on a review process that builds trust and confidence in managing change
be open about the review process by documenting and sharing how it works
be collaborative in the review process by including a variety of people and organisations
consider the consequences of decisions on related policy or legislation as well as on a variety of adopters, including data users, data publishers, guidance users, and developers
Reviewing the standard
There are many ways to review a standard, from systematic reviews that follow a formal process and include review boards, to discovery sessions with groups of adopters and interested parties.
If your standard was developed with a formal standards body, its development process may include steps for reviews. BSI, the national body for standards in the UK, includes routine reviews in its principles of standardisation method.
Other development processes, for example, agile methods – which feature rapid iteration based on agile software development – may include steps that can be repurposed for reviews. Scrum, a commonly used agile method, features sprint retrospectives to help you reflect on and plan for improvements to the open standard.
The process of reviewing the standard might include:
agreeing on the need for review in line with the standard’s governance process
deciding who will perform the review and who will make the final decision to do nothing, update or retire the standard
deciding on the process to follow in line with the standard’s governance process
prioritising what to review from feature requests, error reports or feedback
carrying out the review, documenting and sharing the results
gaining consensus in the community for proposed changes
deciding on the next steps to take: do nothing, update or retire the standard
During the review, it’s useful to focus on the aims and objectives developed while scoping and starting. Questions should focus on real-world use and check:
How well was the standard adopted? In our research ‘User experiences of open standards for data’, we found that the number of people using an open standard was one common indicator of success. You may have targets for types of adopters rather than overall numbers – for example, focusing on national governments or companies of a particular size.
How easy was it to adopt the standard? Feedback from adopters can highlight where the standard is difficult to implement or use. To improve adoption, you can focus on changes that support easy implementation.
What impact has the standard made? In ‘Creating impact with open standards’, we explore delivering a robust open standard by focusing on a clear problem and understanding its ecosystem. In the review, assess the impact the standard has had by examining how well the standard has solved the problem and how the ecosystem has changed since the standard was launched.
How well does the standard work with other standards? To make your open standard easier to adopt and use, we recommend making it interoperable – allowing it to work well with other standards. Assess how well your open standard supports sharing data, open formats, and existing shared vocabularies.
What errors were reported? In ‘Development’, we highlight the importance of a robust standard that has been rigorously tested. At review, consider any errors that have been reported. What changes are needed to fix the errors and improve the testing process?
What changes were requested? Data publishers, data users, guidance users, developers and others using the standard, its products or services may ask for new features or changes to existing features. It’s important to check if a given request is relevant to the standard. Google’s General Transit Feed Specification(GTFS) open standard for sharing public transport information relies on guiding principles to preserve the original aims of the standard and keep it on track.
What resources are available to support change? Updates to the standard will need time, people and funding. It’s useful to consider who can support changes to the standard through partnerships, raising funding or providing time and expertise.
Deciding next steps
Once the review is complete, the decision-makers can decide on the next steps.
Decision-makers may be the standard’s owner or, for example, a governance board made up of key people from the standard’s community. External boards can help keep decisions impartial and so maintain trust in the review process.
Based on the results of the review, the decision can be made to:
do nothing if there is no pressing need for change to the open standard
update the standard by investing funding and resources in improvements
refine the standard by revisiting the ‘Scoping and starting’ stage if adoption is low or the standard doesn’t provide the intended solutions
retire the standard if changes in the landscape (eg new regulations, loss of funding, new standards) mean updates to the standard are no longer necessary
When following the Open Stand principles of working in the open, it’s important to gain consensus in the standard’s community about decisions and proposed changes.
When deciding next steps, it’s useful to have:
clear governance to guide changes and maintain impartiality
real-world scenarios and examples to support continued investment in the standard
a clear understanding of the impact of the proposed changes on a variety of adopters and the wider ecosystem
clear and regular communication with your community to keep them informed of the outcome of the review, decisions and proposed changes
support from a variety of people and organisations in your community for the proposed changes
Expected outputs
Typical outputs at the end of this stage:
documentation of the review process, including who was involved, what was considered and why, how this impacted the decision, and impact of changes
decision on the future of the open standard which may be to do nothing, update and maintain the standard, review the scope, or retire the standard
press releases, blog posts, announcements or other communications with the community to explain the decision and proposed changes
Last updated