| Meets | Requirement | Notes and links |
|---|
|
Ok
|
All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible.
|
All source code is available in GitHub.
|
|
N/A
|
All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible.
|
No policy.
|
|
Ok
|
The codebase MUST NOT contain sensitive information regarding users, their organization or third parties.
|
The content is coming from Wikidata.
|
|
Ok
|
Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published.
|
All source code is available in GitHub.
|
|
|
Documenting which source code or policy underpins any specific interaction the general public may have with an organization is OPTIONAL.
|
|
| Meets | Requirement | Notes and links |
|---|
|
No
|
The codebase MUST be developed to be reusable in different contexts.
|
Govdirectory is optimized to be a one-site deployment.
|
|
Ok
|
The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed software or services for execution and understanding.
|
|
|
No
|
The codebase SHOULD be in use by multiple parties.
|
Govdirectory is optimized to be a one-site deployment so will likely not happen.
|
|
|
The roadmap SHOULD be influenced by the needs of multiple parties.
|
|
|
|
The development of the codebase SHOULD be a collaboration between multiple parties.
|
|
|
No
|
Configuration SHOULD be used to make source code adapt to context specific needs.
|
Govdirectory is optimized to be a one-site deployment so will likely not happen.
|
|
|
The codebase SHOULD be localizable.
|
Partly discussed in issue #27, it is a long-term ambition.
|
|
Ok
|
Source code and its documentation SHOULD NOT contain situation-specific information.
|
|
|
|
Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts.
|
Almost there, but could be improved.
|
|
Ok
|
The software SHOULD NOT require services or platforms available from only a single vendor.
|
While Wikidata is primary, queries could be made to another Wikibase with replicated/mirrored data.
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
The codebase MUST allow anyone to submit suggestions for changes to the codebase.
|
Pull requests are open.
|
|
Ok
|
The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a `CONTRIBUTING` file.
|
CONTRIBUTING
|
|
Ok
|
The codebase MUST document the governance of the codebase, contributions and its community, for example in a `GOVERNANCE` file.
|
In the maintainers section.
|
|
Ok
|
The contribution guidelines SHOULD document who is expected to cover the costs of reviewing contributions.
|
Stated as done by volunteers in CONTRIBUTING.
|
|
Ok
|
The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance.
|
The maintainers section and acknowledgements section covers it.
|
|
Ok
|
The codebase SHOULD have a publicly available roadmap.
|
There is a roadmap board but it needs to be updated.
|
|
Ok
|
The codebase SHOULD publish codebase activity statistics.
|
GitHub pulse
|
|
Ok
|
Including a code of conduct for contributors in the codebase is OPTIONAL.
|
CODE OF CONDUCT
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
The codebase MUST have a public issue tracker that accepts suggestions from anyone.
|
GitHub issues are open and used.
|
|
Ok
|
The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a `README` file.
|
GitHub
|
|
Ok
|
The codebase MUST have communication channels for users and developers, for example email lists.
|
GitHub discussions and Wikidata talk page
|
|
|
There MUST be a way to report security issues for responsible disclosure over a closed channel.
|
|
|
|
The documentation MUST include instructions for how to report potentially security sensitive issues.
|
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
All files in the codebase MUST be version controlled.
|
Git
|
|
Ok
|
All decisions MUST be documented in commit messages.
|
In CONTRIBUTING guidelines.
|
|
Ok
|
Every commit message MUST link to discussions and issues wherever possible.
|
In CONTRIBUTING guidelines.
|
|
Ok
|
The codebase SHOULD be maintained in a distributed version control system.
|
Git
|
|
|
Contribution guidelines SHOULD require contributors to group relevant changes in commits.
|
|
|
|
Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels.
|
Versions are not used yet.
|
|
|
Contribution guidelines SHOULD encourage file formats where the changes within the files can be easily viewed and understood in the version control system.
|
|
|
|
It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work.
|
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor.
|
In CONTRIBUTING guidelines.
|
|
Ok
|
Reviews MUST include source, policy, tests and documentation.
|
|
|
Ok
|
Reviewers MUST provide feedback on all decisions to not accept a contribution.
|
|
|
Ok
|
The review process SHOULD confirm that a contribution conforms to the standards, architecture and decisions set out in the codebase in order to pass review.
|
In CONTRIBUTING.
|
|
Ok
|
Reviews SHOULD include running both the software and the tests of the codebase.
|
|
|
|
Contributions SHOULD be reviewed by someone in a different context than the contributor.
|
|
|
|
Version control systems SHOULD NOT accept non-reviewed contributions in release versions.
|
|
|
|
Reviews SHOULD happen within two business days.
|
Too small community still, current ambition is a week.
|
|
|
Performing reviews by multiple reviewers is OPTIONAL.
|
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
All of the functionality of the codebase, policy as well as source code, MUST be described in language clearly understandable for those that understand the purpose of the codebase.
|
|
|
Ok
|
The documentation of the codebase MUST contain a description of how to install and run the software.
|
|
|
|
The documentation of the codebase MUST contain examples demonstrating the key functionality.
|
|
|
|
The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the general public and journalists.
|
In README, but can be clearer.
|
|
Ok
|
The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset.
|
|
|
|
The documentation of the codebase SHOULD contain examples for all functionality.
|
|
|
|
The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram.
|
|
|
|
There SHOULD be continuous integration tests for the quality of the documentation.
|
|
|
|
Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL.
|
|
| Meets | Requirement | Notes and links |
|---|
|
|
The set of authoritative languages for codebase documentation MUST be documented.
|
|
|
|
English MUST be one of the authoritative languages.
|
|
|
N/A
|
All codebase documentation MUST be up to date in all authoritative languages.
|
|
|
Ok
|
All source code MUST be in English, except where policy is machine interpreted as code.
|
|
|
N/A
|
All bundled policy MUST be available, or have a summary, in all authoritative languages.
|
|
|
Ok
|
There SHOULD be no acronyms, abbreviations, puns or legal/language/domain specific terms in the codebase without an explanation preceding it or a link to an explanation.
|
|
|
Ok
|
Documentation SHOULD aim for a lower secondary education reading level, as recommended by the Web Content Accessibility Guidelines 2.
|
|
|
|
Providing additional courtesy translations of any code, documentation or tests is OPTIONAL.
|
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
For features of the codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the Open Source Initiative Open Standard Requirements.
|
|
|
N/A
|
Any non-open standards used MUST be recorded clearly as such in the documentation.
|
|
|
Ok
|
Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available.
|
CONTRIBUTING
|
|
Ok
|
Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse.
|
|
|
N/A
|
If no existing open standard is available, effort SHOULD be put into developing one.
|
|
|
Ok
|
Open standards that are machine testable SHOULD be preferred over open standards that are not.
|
|
|
N/A
|
Non-open standards that are machine testable SHOULD be preferred over non-open standards that are not.
|
|
| Meets | Requirement | Notes and links |
|---|
|
|
All functionality in the source code MUST have automated tests.
|
Doing full testing would require running all queries live towards Wikidata, and that is something we should be restrictive with. Instead we are pondering what tests could be meaningful and cheap and will add as we go.
|
|
|
Contributions MUST pass all automated tests before they are admitted into the codebase.
|
|
|
|
The codebase MUST have guidelines explaining how to structure contributions.
|
|
|
Ok
|
The codebase MUST have active contributors who can review contributions.
|
|
|
|
Automated test results for contributions SHOULD be public.
|
|
|
|
The codebase guidelines SHOULD state that each contribution should focus on a single issue.
|
|
|
|
Source code test and documentation coverage SHOULD be monitored.
|
|
|
|
Testing policy and documentation for consistency with the source and vice versa is OPTIONAL.
|
|
|
|
Testing policy and documentation for style and broken links is OPTIONAL.
|
See [issue #289](https://github.com/govdirectory/website/issues/289)
|
|
|
Testing the software by using examples in the documentation is OPTIONAL.
|
|
| Meets | Requirement | Notes and links |
|---|
|
Ok
|
The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding.
|
|
|
Ok
|
The codebase SHOULD have a short description that helps someone understand what the codebase is for or what it does.
|
|
|
Ok
|
Maintainers SHOULD submit the codebase to relevant software catalogs.
|
Digital Public Goods Registry, Civic Tech Field Guide and Toolhub.
|
|
Ok
|
The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers).
|
govdirectory.org
|
|
Ok
|
The codebase SHOULD be findable using a search engine by codebase name.
|
|
|
Ok
|
The codebase SHOULD be findable using a search engine by describing the problem it solves in natural language.
|
|
|
Ok
|
The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, repository location and website.
|
Wikidata: Q108109790
|
|
|
The codebase SHOULD include a machine-readable metadata description, for example in a publiccode.yml file.
|
|
|
Ok
|
A dedicated domain name for the codebase is OPTIONAL.
|
govdirectory.org
|
|
Ok
|
Regular presentations at conferences by the community are OPTIONAL.
|
Events listing
|