Skip to content
ShahimEssaid edited this page Dec 5, 2014 · 3 revisions

The following describes how to use and manage issue trackers for VIVO-ISF projects.

Where are the trackers?

We currently have a single GitHub issue tracker. It exists in the vivo-isf-data-standard repository, the same repository as this wiki.

The goal is to have a single entry point for issues but still allow additional areas where issues can be managed, if needed. Unless there is a very good reason for going to any other repository's issue tracker, all issues should start in this single issue tracker.

Other relevant trackers outside the VIVO-ISF organization are:

  • ?

Why not repository-specific trackers?

It is a choice. We can revisit this choice later once there is a good reason for a change. However, for users that prefer a single issue tracker, be aware that GitHub provides a way for viewing cross repository issues for an organization. For example, the following link takes you to all the open VIVO-ISF issues in different repositories:

https://github.com/issues?q=is%3Aopen+user%3Avivo-isf

If this satisfies the need for a single tracker, and splitting the single tracker across different repositories has some value, we might want to rethink our current choice.

But there are issues in individual repositories. Why?

The above choice does not mean that repository and project owners can't use their own issue trackers. That would be their own choice. One reason for doing this is to keep very low level development issues related to commits, etc. away from the single "community" or "end user" tracker that is more focused on use cases, collaboration, etc.

Based on this, if you see any issues in trackers other than the single master tracker, consider those issues and tracker as private to the owners and committers for those repositories.

How should issues be organized?

Since we are using a single tracker for all issues, and GitHub's main management tool for issues is labels, we could have labels to indicate which repository is affected by the issue. For example, a label like "contribution" could be used to indicate that the issue is about the contribution ontology repository in the VIVO-ISF organization. Also, to help organize the labels themselves, it might help help to have a prefix to indicate the label type. For example, the "contribution" label could be "r contribution" to indicate that it belongs to the contribution (r)epository.