» home
» bugs
» git
 

Bug Tracker

Usage

One should use the bug tracker to report issues with LiteStep only after discussion occurs with another person who can agree with you on the issue. Ideally this discussion would take place on the LiteStep development mailing list. The usage guidelines for Users should be followed anytime an issue is be submitted, or responded to. The usage guidelines for Developers should be followed anytime you are updating/ resolving a reported issue.

Users

When you believe you have determined a feature, bug or other item that you would like to let people know about, please follow these guidelines. If you decide that some part of this does not apply to you, most likely the developers reading your issue will decide that some part or all of it does not apply to them. If you see these guidelines as important, the developers will see your issue as important. It is not a matter of being picky, it is a matter of only having 24 hours in a day, not all of which are usable.

It is OK if you do not know the answer to all of the questions that are asked when reporting an issue, but the more you research and can tell the developers, the quicker they will be to look into your issue.

When submitting an issue, there are several things to keep in mind in order to be able to create a useful and easily manageable issue report.

  • Make sure the report is well formatted and all relevant fields in the report form are assigned.
  • Make sure to include all information needed to understand and recreate the issue. The best way to ensure this, is to discuss the issue with someone else prior to reporting the issue.
  • Watch the issue after you submit it and promptly follow up with any requested information. The best way to do this is to enable "Monitor Issue" and in your account preferences ensure your email settings are correct.

Guidelines to Issue Reporting and Follow Up

  1. Search for existing issues in the bug tracker using keywords related to your issue.
  2. Discuss the issue (whether you found an existing issue or not) with someone else, preferably on the developer mailing list.
  3. Document your findings in a legible manner.
  4. If there is agreement on your findings, log them in the bug tracker. Either in an existing issue or a new issue if no related issue already exists.
  5. Prior to submitting a new issue, be able to answer the following questions:
    1. Can you reproduce the problem? How?
      • When filling in the "Reproducibility" field, be completely honest.
      • Don't expect the developers to know anything about your situation.
      • Be detailed in the steps to reproduce the problem.
    2. Is this a bug, or a feature?
    3. Can you give a distinct one line Issue Summary? What is it?
    4. Do you have a detailed Issue Description? What is it?
    5. What additional information do you have regarding this issue that was not necessary to describe the issue?
    6. What project does this issue relate to?

Developers

Managers

Reference

Projects

Issue Status

Feedback: A newly submitted issue and/or further information is needed before we can confirm or start working on the issue.

Confirmed: The issue has been confirmed, and it appears to be valid, we'll get to it eventually.

Resolved: The issue has been fixed and committed to the source repository.

Closed: If the issue was fixed, then the issue has been included in a release. If the issue was not fixed, then it was invalid and simply closed.

Issue Category

Specifies the component the issue report is related to.

Issue Severity

The reported issue is…

feature …a feature request.

trivial …of trivial importance.

text …concerns text issues. eg. documentation, or UI output.

tweak …a slight change; hopefully for the better.

minor …a minor bug/ problem.

major …a bug that causes usability problems.

crash …a bug that results in a crash/ lockup.

block …an issue that must be fixed prior to any related issues being resolved. Prevents another release from occuring until resolved.

Issue Summary

A concise, distinct summary of the issue.

Issue Description

A description of the issue. This should detail the issue, but not contain the "Steps to Reproduce", which should be included below.

Steps To Reproduce

Any bug/ issue report must have the ability to reproduce the issue. Without this, it might take much longer to be resolved. Provide a detailed walk through of reproducing the issue.

Additional Information

Please provide system configuration information if applicable. Also provide links and resources to any related tools, utilities, applications that are affected by the issue being reported.

 
lsdev/bugs.txt · Last modified: 2009/01/27 17:48 by jugg
 
Recent changes RSS feed Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki