Principle: Responsiveness (principle 20)

• Overview
• 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)

Summary

Ontology developers MUST offer channels for community participation and SHOULD be responsive to requests.

This check is automatically validated.

Purpose

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:

1. 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.
2. If an issue cannot be addressed right away, explain when you plan to address the issue.
3. Do not close issues without responding. If an issue is out of scope for a repository, recommend moving it to a different repository.
4. It is recommended that one or more developers be designated to triage issues.

Implementation

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).

1. 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.
2. Optional: Establish a discussion forum (For example, Google groups mailing list, Slack, Twitter).
3. The issue tracker and (if any) discussion forum SHOULD be monitored and responded to within 2-5 working days.

Review Criteria

There is a functioning issue tracker for ontology requests specified on the OBO Foundry web site.

Examples

Issue tracker: https://github.com/monarch-initiative/mondo/issues

Discussion list: mondo-users@googlegroups.com

Collaboration of this sort can be demonstrated by having an active discussion mailing list, or responsiveness to community requests on a GitHub tracker.

Counter-Examples