Principle: Responsiveness (principle 20)
- Open (principle 1)
- Common Format (principle 2)
- URI/Identifier Space (principle 3)
- Versioning (principle 4)
- Scope (principle 5)
- Textual Definitions (principle 6)
- Relations (principle 7)
- Documentation (principle 8)
- Documented Plurality of Users (principle 9)
- Commitment To Collaboration (principle 10)
- Locus of Authority (principle 11)
- Naming Conventions (principle 12)
- Notification of Changes (principle 13)
- Maintenance (principle 16)
- Responsiveness (principle 20)
Ontology developers MUST offer channels for community participation and SHOULD be responsive to requests.
Ontology development benefits from community input, which is strongly encouraged by the OBO Foundry. Accordingly, “responsiveness” is a key quality of our general collaborative spirit. This principle is intended to ensure that channels for community input are available and that responses to input are given swiftly.
Recommendations and Requirements
Ontology developers MUST set up a public mechanism to track community requests and suggestions (collectively, “issues”), and SHOULD aim to respond within 2-5 working days. To facilitate submission of well-crafted issues, ontology developers SHOULD create a set of guidelines/instructions for contributions. Optional: Establish a discussion forum for more general communication with and between users.
Expectations of responsiveness:
- Issues are contributions - and should be met by a thankful attitude. When receiving an item on your issue tracker, the first thing to do is thank the contributor, even if it cannot be addressed right away.
- If an issue cannot be addressed right away, explain when you plan to address the issue.
- Do not close issues without responding. If an issue is out of scope for a repository, recommend moving it to a different repository.
- It is recommended that one or more developers be designated to triage issues.
Issue tracker: Specify the URL for an issue tracker (GitHub is recommended) in the ontology configuration file (YAML) that is used to display ontology details on the OBO Foundry web site. Specification of the tracker is done using the following text (customized for your ontology) within its metadata file:
tracker: <URL pointing to issue tracker>
Guideline for contributions (recommended): Create a file called ‘CONTRIBUTING.md’ (example) in an easy-to-find main folder for the appropriate ontology (for example, in the root directory of the ontology GitHub repository, where one would expect to find LICENSE or README files). Learn more about contribution guidelines here).
Discussion forum (optional): Establish a discussion forum (For example, Google groups mailing list, Slack, Twitter). Each of these is specified in the configuration file as given below:
mailing_list: <email address>
twitter: <twitter handle>
slack: <URL pointing to slack channel>
Issue tracker: https://github.com/monarch-initiative/mondo/issues
Mailing list: firstname.lastname@example.org
Specifying a private issue tracker. Waiting until an issue is resolved before responding, if such resolution comes well after submission of a ticket.
Criteria for Review
There is a functioning public issue tracker for ontology requests specified on the OBO Foundry web site.
Feedback and Discussion
To suggest revisions or begin a discussion pertaining to this principle, please create an issue on GitHub.
To suggest revisions or begin a discussion pertaining to the automated validation of this principle, please create an issue on GitHub.