Triage Bugs: Difference between revisions

From GNU MediaGoblin Wiki
Jump to navigation Jump to search
(initial triage bugs page)
 
(Add small summary of most used keywords in the tracker.)
Line 8: Line 8:


For help, instructions, and suggestions be in touch with the development community on the list or in the IRC channel for more information. With many eyes, all bugs are shallow.
For help, instructions, and suggestions be in touch with the development community on the list or in the IRC channel for more information. With many eyes, all bugs are shallow.

=== Bug keywords ===
* "bitesized" for bugs that should be easy to fix, even for beginners.
* "review" for bugs, that have a patch (branch!) associated and someone should look at that branch and likely merge it into master
* "sql" for things relating to our sql data model.

Revision as of 12:03, 19 February 2013

The triage process involves reviewing bugs, removing duplicates, validating that the issues described are reproducible, ensuring that the exact behavior is properly documented, diagnosing the cause of each issue, and working with developers to ensure that critical bugs get addressed. In many cases, developers do this kind of work as a matter of course, but one need not be able to code in order to help working with bugs.

To triage bugs, go to the bug tracker and begin reviewing the open issues. If you are able, attempt to:

  • ensure that one or two people in addition to the initial reporter have been able to reproduce the issue.
  • document the issue more clearly. If you had any trouble reproducing the issue, provide any elucidating information that you can to help others solve the problem more effectively.
  • find a way to resolve the problem or provide a workaround.

For help, instructions, and suggestions be in touch with the development community on the list or in the IRC channel for more information. With many eyes, all bugs are shallow.

Bug keywords

  • "bitesized" for bugs that should be easy to fix, even for beginners.
  • "review" for bugs, that have a patch (branch!) associated and someone should look at that branch and likely merge it into master
  • "sql" for things relating to our sql data model.