Skip to content
This repository has been archived by the owner on Aug 6, 2021. It is now read-only.

Guidelines for Issues

Jump to bottom
ccaudill edited this page Mar 31, 2014 · 5 revisions

Please add issues using the GitHub issue tracker for this installing and running the NGDS NIAB. You will need to have a GitHub login in order to create an issue. Join GitHub if you don't already have an account; its easy, free, and handy for all kinds of collaborative projects.

General Remarks

An issue can be almost anything that is worth tracking, from a bug to a new idea to a customer request. Feel free to insert screen shots; they help a lot. For bugs, please provide instructions for reproducing the bug. For issues raised by non-developers, please include

  • the original text AND
  • your "translation" into what it means for developers.

General Workflow

  1. New Issue
  2. Write description
  3. Optional: add screen shot(s) if helpful
  4. Add tag(s) please (see list of tags, below)
  5. Developer adds In Progress tag when s/he begins actively working on the issue.
  6. All can make comments
  7. All can revise tags
  8. Developer adds a test case that can be executed from a client UI.
  9. Developer adds a resolution tag
  10. Developer replaces in-progress with pending merge tag
  11. When code resolving the issue is merged into the test system, replace pending merge with in-test tag and assigns issue to a tester.
  12. Tester confirms resolution, removes in-test and Closes the issue.

Changing the subject

If you uncover a new issue while resolving an existing one, you have two choices:

  • if the new issue completely replaces or subsumes the old one, you can change the title and description of the issue to reflect it, and revise the tags accordingly.
  • if the old issue has had a significant life of its own, please create a new issue rather than rewriting the old one.

Status Tags (light blue)

Github classifies an issue as either Open or Closed. The following tags are normally only used for Open issues; if found on a Closed issue, it should normally be re-opened.

  • check tags: The status of the issue is unclear because the tags might not correctly characterize it.
  • in-progress: The issue is assigned to someone and that person is attempting to analyze and resolve it.
  • pending merge: The issue implementation has not yet been merged into the test system.
  • in-test: The issue has been tentatively resolved, but has not yet been independently tested.

Resolution tags (light yellow)

When a developer has finished analyzing an issue and attempting to resolve it, s/he adds one of the following tags:

  • fixed: The issue has been adequately resolved (bug fixed, feature implemented, question answered, data repaired, etc.)
  • duplicate: The issue more-or-less duplicates another issue. Its content has been incorporated into the other issue.
  • invalid: As written, the issue is not true, not relevant, out of scope, or otherwise invalid. If the author feels strongly about it, s/he should confer, rewrite, and resubmit as a new issue.
  • wontfix: Although the issue is valid, it won't be fixed.
  • defer: The issue will not be addressed in the current development cycle.
Clone this wiki locally