A formalized governance model for the creation, acceptance, and upkeep of Open Civic Data Division Identifiers (OCDIDs).
Recently, a number of civic data organizations, tech companies, and US state governments have expressed interest in taking a greater role in the creation, upkeep, and wider adoption of OCDIDs. Currently, the governance structure for division IDs as defined in OCDEP2 is “informal... led by the project’s early contributors and informed by the Open Civic Data Google Group.” Increased adoption and interest makes this informality untenable for reasons including:
We propose to formalize this structure in order to relieve some of the burden on those currently responsible for maintaining the repository, as well as allowing those whose work depends on OCDIDs to have more direct control on their upkeep.
Anyone using OCDIDs may contribute through group discussion, reporting issues, or assisting with subject-matter expertise. The agreed upon communication channels for each country’s community will be publicly displayed in the Open Civic Data documentation.
Any individual or organization user may become a contributor by submitting a pull request adding, correcting, or aliasing jurisdictional OCDIDs. First time contributors will be advised via a CONTRIBUTING.RST to consult with an existing committer from their country before submitting their first PR.
Committers have the ability to approve and commit pull requests from contributors and other committers within their geographic scope.
An initial cohort of committers will be determined by current project contributors. A public list of committers will be maintained in a separate OCDEP.
A separate committers communication channel for each country-based community will be established. A list of each country’s committer email addresses will be maintained and email will be used to conduct official actions unless otherwise specified.
Any individual who is a contributor and who agrees to the responsibilities listed here may request to become a committer``via a country's agreed upon communication channel. That request will then be shared with the group of that country's current ``committers for approval.
Committers will be approved on an individual basis. Multiple committers from the same organization are permitted, though should be limited to a reasonably small set of individuals. Organizations should work with the current committer cohort to ensure that new members are approved in a timely manner and to transition departing members out of the community if necessary.
Committers are expected to participate in good faith in approval, support, maintenance, and other community related activities or may have their committer status revoked. A committer who believes the behavior of another committer is detrimental to the project should take the following steps:
Any contributor may create a pull request for generative IDs, corrections, aliases, etc.
Commits should be reviewed within 2 weeks of a pull request. Accelerated timeline needs should be communicated via the country’s communication channels.
Some local division identifiers, such as those for special districts in the US, may be difficult to verify for anyone besides the pull request submitter. Committers should consider the both the source as well as the scope of the change requested in determining the level of scrutiny necessary for approving a pull request.
If pull requests are languishing due to committer inaction, a country’s committers may implement a mechanism for automatically approving a pull request after a certain time.
If a conversation around a request cannot reach consensus, after two months the person who made the pull request may request a final vote from the country’s committers.
Approval will be handled on a per-file, rather than a per-commit, basis.
New commits should include well-formed explanations, especially if generating new IDs or types.
Formalized guidelines for approval will be created for use by committers. These guidelines will include:
Should a government entity wish to contribute to the repository, they will initially be asked to work directly with an existing committer to prepare to integrate their identifier set.
Government entities (and the committers they work with) will be expected to reconcile and appropriately alias these cases with existing OCDIDs in order to ensure maximum compatibility.
Identifiers created by government officials that are used in official data will be marked as such in the repository, so that developers can quickly identify the preferred identifier in case of conflict. Caution should be used, and the original submitter consulted with if possible, before changing government submitted identifiers.
A section of documentation specifically aimed at government staff will be created, where they can learn more about the project and how to get involved, as well as how to reach out to the community to get help.
Committers will be expected to participate in a quarterly review of their country’s new OCDIDs in order to ensure quality on-going. Committers will be requested to contribute and maintain an ongoing style guide for creating new district types. Committers will be required to participate in > 60% of their country’s formal votes/actions as announced.
This document has been placed in the public domain per the Creative Commons CC0 1.0 Universal license (http://creativecommons.org/publicdomain/zero/1.0/deed).