Issue Tracker: /home/

_Documentation

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

Using the issue tracker provides a number of benefits.

Feature requests should reflect standalone pieces of functionality that can be individually tested. They should reflect no more than 1-2 days of work.
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.

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

The basic life cycle of an issue looks like this:

An issue is entered into the issue tracking system. Issues may be features (type "todo"), bugs (type "defect"), spec issues, documentation requirements, etc.
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.
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.
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.