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)
- 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 mechanism to track community requests and suggestions (collectively, “issues”), and SHOULD aim to respond within 2-5 working days. 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.
A discussion mailing list and issue tracker are required to obtain an OBO Foundry PURL. The OBO Foundry offers the following recommendations on the responsiveness in issue trackers (GitHub is recommended).
- 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.
- Optional: Establish a discussion forum (For example, Google groups mailing list, Slack, Twitter).
Specification of the tracker is done using the following text (customized for your ontology) within its metadata file:
Issue tracker: https://github.com/monarch-initiative/mondo/issues
Discussion list: firstname.lastname@example.org
Collaboration of this sort can be demonstrated by having an active discussion mailing list, or responsiveness to community requests on a GitHub 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 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.