Roles and responsibilities

Understanding the roles and responsibilities in standards development

To develop an open standard successfully it’s important to involve a wide variety of people and organisations. To support collaboration it can be helpful to assign roles and responsibilities within the team working to develop a standard.

We have identified some of the key roles involved in designing, creating and maintaining a successful open standard for data.

For each role we have identified some of their responsibilities and suggested advice for people taking on these responsibilities.

Role Responsibility
Chair Lead the standardisation group, establish consensus with responsibility for governance and managing change.
Authors and editors Document decisions and write the specifications for the standard, in line with the decisions. Role includes sharing drafts and changes and gathering feedback from the community.
Testers and implementers Create and maintain the test framework to ensure implementability and interoperability of the standard being developed. Gather and construct feedback on the quality of the specification and the fitness for purpose of the standard.
Reviewers and contributors Submit input on use cases and requirements, and contribute editorial and substantial comments on the draft standard.


Key responsibilities:

  • Lead the standardisation group to consensus on all matters requiring a decision.
  • Be in charge of governance and managing change
  • Ensure standard meets the needs of its audience
  • Drive consensus
  • Ensure that a broad set of views are heard and respected

Read the definition of chair’s role in the BSI guide to standardisation

A key aspect of the role is balancing the importance of schedules and timings, with ensuring all voices are heard and respected.

Knowledge of effective consensus-building techniques, as well as an awareness of some of the patterns of sabotage can be key to effective chairing.

The role involves ensuring that decisions are fully and accurately documented and are available for all group members to access and comment on. This will help ensure there is an accurate record of decisions and action points which will help reduce repetition.

While it is the chair’s responsibility to build consensus, this does not always succeed and extended disagreements can be damaging. Organisations such as the W3C have formal processes in place for the management of formal objections and dispute resolution.

Authors and editors

Key responsibilities:

  • Write the specification(s) for the standard being developed, in line with the decisions made by the standardisation group
  • Share drafts early, highlighting changes to the community to encourage feedback, ensuring there are good feedback channels
  • Help document decisions to ensure there is a trail showing how the standard was created, making it easier to evolve and improve.

Some standards organisations, such as the W3C describe the role as ‘editor’ – rather than ‘author’ – who, as well as ensuring that the specification is developed with clarity, consistency and excellence, also act as a conduit for other people’s ideas.

High-quality and accurate documentation is key the role of editor/author. It is crucial to keep an accurate record of:

  • decisions by the group
  • use cases and requirements
  • and how these are translated into a formalised specification.

It is crucial for authors/editors to be able to write clearly and concisely in plain language. They should have a good understanding of technical design. In many cases, a standard body will have a style guide or similar structure and drafting rules for editors and authors.

Testers and implementers

Key responsibilities:

  • Create and maintain the test framework to ensure implementability and interoperability of the standard being developed
  • Gather and construct feedback on the quality of the specification and the standard’s fitness for purpose

The key purpose of an open standard is that it can be easily implemented in an interoperable way. Ensuring ease of implementation and interoperability is a complex process and requires particular skills and experience.

It is important to be aware of the far-reaching consequences of, eg, a single unclear statement in a specification which can lead to issues for future implementations.

Testers and implementers also help ensure features are realistic and well researched, and able to be implemented effectively.

Standards groups use different styles – from reference implementation to test-driven development. Regardless of the style used, most of the time a successful standard development project will involve early implementation and comprehensive testing. Therefore testers and implementers, whether they are setting up a test framework, contributing test cases or feeding back on implementation experience, are key roles in a standard development group.

Reviewers and contributors

Key responsibilities:

  • Depending on the phase of development of the standard, the role of contributors and reviewers can range from submitting input on use cases and requirements, to contributing editorial and substantial comments on the draft standard.

While not often given a specific role in a standardisation working group, contributors have an overall important impact on the quality of the resulting standard and on the effectiveness of the process.

Most contributors will see their role as helping the author and chair do their job. They will focus on changes/issues as guided by the chair/author, submit changes or comments in a timely manner, respect previous decisions and avoid reopening previous debates.

They will also be in charge of gathering feedback from the broader community on the quality of the specification and the fitness for purpose of the standard.

How to use this guide

There are a number of ways for you to learn more about the creation, development and adoption of open standards for data.

About this guide

This guidebook helps people and organisations create, develop and adopt open standards for data. It supports a variety of users, including policy leads, domain experts and technologists.

Something missing? Suggest a change or addition