Triage Bugs

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/tags

• "bitesized" for bugs that should be easy to fix, even for beginners.
• (Probably outdated with new bug status system) "review" for bugs that have a patch (branch!) associated and someone should look at that branch and likely merge it into master
• "longterm" for bugs, that are planned to happen at some point. There is no immediate need to take action. If the bug has been without traffic for more than a year, we might reconsider the thing.
• "sql" for things relating to our sql data model.
• "video" for things relating to the video media type
• "audio" for things relating to the audio media type

• "test" may have no strict meaning defined yet, but it is used for bugs that need a test (unit or functional) written, or are about tests.

See also

• BugTriageDay — every other Thursday
• TriageWorkflow — for discussion