Principle: Responsiveness (principle 20)

This page is generated via _layouts/principle.html. See edit guide

GO TO: Recommendations/Requirements | Implementation | Examples/Counter‑Examples | Criteria for Review | Feedback/Discussion

Summary

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

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 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:

  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

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>

Examples

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

Mailing list: mondo-users@googlegroups.com

Twitter: diseaseontology

Slack: https://geneontologyworkspace.slack.com

Counter-Examples

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.

This check is automatically validated.

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.