Outputs and Activities Checklist

Developing an open standard for data means combining technical activity, stakeholder coordination and community engagement. Use this checklist to track typical activities and outputs for each stage of

Getting started

❐	Understand the problem the open standard will solve and why it is the right solution
❐	Evaluate the benefits of the open standard, including who will benefit and how
❐	Engage with others who share the same problem to build a community that could benefit from the open standard
❐	Identify the community of people and organisations who will use or be affected by your open standard
❐	Decide on early adopters – the people and organisations who will be the first to use the open standard and help to scope and develop it
❐	Identify the type of open standard that will deliver the most benefits or choose the features that might be combined from each
❐	Plan to sustain the standard and who can help with securing funding, resourcing development, creating guides, engaging in advocacy and more
❐	Decide how to manage change with a governance process that makes it clear who manages change, how change is managed and how often the open standard will be updated
❐	Develop guides for sharing data that focus on improving data quality and access to data
❐	Research existing open standards that can be built on, extended or adapted for your needs
❐	Develop an open standards for data canvas that provides a single view of the open standard: the problem, solution, community, resources, risks and impacts
❐	Understand and map the ecosystem the standard will operate in, including the data infrastructure

Scoping and starting

❐	Develop a theory of change to clarify the aims and objectives of the open standard
❐	Develop conceptual models or other diagrams that visualise the concepts, flow of information, or scenarios for the open standard
❐	Create stakeholder and empathy maps of who will use or be affected by the open standard and how
❐	Decide on core features that are essential to successful use of the open standard
❐	Decide on features that make the open standard interoperable (works well with existing standards) by reusing existing formats, vocabularies, identifiers and more
❐	Decide on features that make the open standard adaptable and extendable so it can be used in a variety of real-world scenarios
❐	Decide where the open standard will be used and what languages must be supported for the technical documents, guides and other resources
❐	Design tests for the open standard that reflect the real-world scenarios that adopters will encounter when they use it
❐	Design with the five Open Stand principles so the open standard is developed fairly, transparently and cooperatively
❐	Decide how to keep in touch with the standard’s community as the standard is developed
❐	Decide who owns intellectual property on the open standard and contributions from others
❐	Choose a development method and development partner that suit the aims of the open standard and the needs of the stakeholders
❐	Decide on an open license for the standard — choose a license that allows anyone to access, use and share the open standard
❐	Decide on phases of work in line with the chosen development method and governance process
❐	Create a plan for the development that outlines the scope, schedule, features and budget for the development stage
❐	Get approval to begin development from the standards owner, funder, or others with a responsibility for managing the standard

Development

❐	Assemble a team to develop the open standard and include a wide variety of people and organisations to design, test and review the open standard
❐	Set up a development infrastructure that supports transparency, sharing, automated testing, tracking changes, reporting errors and providing contributions
❐	Develop the open standard by drafting guidance, creating data, or creating formats — activities will depend on the type of open standard or core features selected
❐	Test the open standard to make sure it works in a variety of real-world scenarios that adopters are likely to encounter
❐	Test resources and tools developed with the open standard, including test data, tools for validation, tools for publishing, tools for analysis, and code libraries
❐	Test integration with other standards – for example shared vocabularies, use of identifiers and more
❐	Automate and share testing to make sure testing is rigorously applied and give others the opportunity to provide feedback
❐	Create guides and resources for different audiences to make the open standard easier to adopt and use
❐	Share progress and activity with the standard’s community to encourage early feedback and review of the open standard
❐	Track issues reported during development to ensure they are resolved and to help improve testing of the open standard
❐	Produce a working version of the open standard in human-readable and machine-readable formats
❐	Produce translations of the open standard, guides and resources, including website content if multiple languages are supported
❐	Record and share early adopter experiences to help others use and share the open standard

Adoption and launch

❐	Organise a launch event to promote the open standard to a wide audience
❐	Share a stable version of the open standard and resources to make it easy to find, share and use
❐	Update the stakeholder map to include new groups of people and organisations who can support, use or be affected by the open standard
❐	Promote stories that demonstrate the benefits of the open standard with the media, in academia, on blogs, through podcasts, tool demonstrations and more
❐	Share the journey of developing your open standard with other standards communities to find allies
❐	Provide tutorial and training sessions to guide developers and adopters through implementing or using the open standard
❐	Set up a technical helpdesk to field questions, provide support, training and outreach for the open standard
❐	Set up an engagement and advocacy team to work with organisations and policy groups to improve support for the open standard
❐	Set up a forum online or offline where anyone interested in the open standard can ask questions and find others who are implementing or using the the open standard
❐	Encourage the development of tools that support adopters of the standard, including use of data, guidance or models
❐	Track direct uses of the open standard, including sharing or using data and guidance as part of the standard’s adoption statistics
❐	Track indirect uses of the open standard including development of tools and integration into products and services as part of the standard’s adoption statistics
❐	Track mentions of the open standard in the media, social media, in research and other avenues as part of the standard’s communication and media statistics
❐	Collect case studies and other research about the standard and how it is used in real-world scenarios
❐	Update the ecosystem map to understand what’s changed in the data infrastructure since the open standard was launched

Review

❐	Determine the review schedule in line with the standard’s governance
❐	Decide on an open, collaborative review process and share with the standard’s community
❐	Decide who will perform the review and make the final decision to do nothing, update or retire the open standard
❐	Prioritise what to review from feature requests, error reports and other feedback
❐	Perform the review by considering how well the open standard was adopted, how easy it was to adopt, the impact the standard has made, how interoperable the standard is, what errors were reported, what changes were requested and what resources are available to support change
❐	Decide on next steps – do nothing, update or retire the open standard
❐	Share documentation of the review including who was involved, what was considered and why, and the impact of proposed changes
❐	Track the impact of proposed changes to the open standard on a variety of people and organisations including adopters, developers, policy and more
❐	Gain consensus in the standard’s community for proposed changes
❐	Announce the decision to the community through press releases, in forums, through blog posts, on notice boards and other channels

Update or retire

❐	Determine if updates include breaking or other changes that will require a major version release and communicate this clearly to adopters
❐	Determine if updates include minor changes and communicate this clearly to adopters
❐	Determine the next version number of the open standard and any affected resources
❐	Determine if translations should be updated to take into account any new versions
❐	Review test suites and test data to determine which are affected by proposed changes
❐	Review tools and code libraries that use the open standard to determine which are affected by proposed changes
❐	Announce changes in good time by sharing a list of changes with adopters and developers so they have time to plan for new versions
❐	Circulate decisions to retire to the community and on available channels if necessary
❐	Transfer intellectual property to the community or other organisations to continue maintenance of the standard if necessary
❐	Close the standard's website and forum to prevent new updates and preserve their contents where possible
❐	Archive content to websites like Internet Archive or repositories like Github if domains are to be shut down