Open Source Project: Entering Issues

For general documentation on using the issue tracker see Issue/Bug Tracking.

Finding the LabKey issue tracker

All LabKey Server development issues are tracked in our issue tracker.


Using the issue tracker provides a number of benefits.

  • Clear ownership of bugs and features.
  • Clear assignment of features to releases.
  • Developers ramp down uniformly, thanks to bug goals.
  • Testing of all new features and fixes is guaranteed.

Guidelines for Entering Feature Requests

  1. Feature requests should reflect standalone pieces of functionality that can be individually tested. They should reflect no more than 1-2 days of work.
  2. Feature requests should contain a sufficient specification (or description of its SVN location) to allow an unfamiliar tester to verify that the work is completed.

Guidelines for Entering Defects

  1. Include only one defect per opened issue
  2. Include clear steps to reproduce the problem, including all necessary input data
  3. Indicate both the expected behavior and the actual behavior
  4. If a crash is described, include the full crash stack

Issue Life Cycle

The basic life cycle of an issue looks like this:

  1. An issue is entered into the issue tracking system. Issues may be features (type "to do"), bugs (type "defect"), spec issues, documentation requirements, etc.
  2. The owner of the new issue evaluates it to determine whether it's valid and correctly assigned. Issues may be reassigned if the initial ownership was incorrect. Issues may be resolved as "Not reproducible", "Won't Fix", or "Duplicate" in some cases.
  3. The owner of the issue completes the work that's required and commits the change to source control (or makes configuration changes to the system in question, etc), and resolves the issue. If the owner opens the issue to themselves (as is common for features), the owner should assign the resolved bug to someone else. No one should ever close a bug that they have resolved.
  4. The owner of the resolved issue verifies that the work is completed satisfactorily, or that they agree with any "not reproducible" or "won't fix" explanation. If not, the issue can be re-opened to the resolver. If the work is complete, the issue should be closed. Issues should only be reopened if the bug is truly not fixed, or if the feature is truly incomplete. New or related problems/requests should be opened as new issues.

Related Topics


Was this content helpful?

Log in or register an account to provide feedback

expand all collapse all