Triage Bugs

From GNU MediaGoblin Wiki
(Difference between revisions)
Jump to: navigation, search
(Update bug tags)
(Bug keywords/tags: "test")
Line 10: Line 10:
  
 
=== Bug keywords/tags ===
 
=== Bug keywords/tags ===
* "bitesized" for bugs that should be easy to fix, even for beginners.
+
* '''"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
+
* (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.
+
* '''"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.
+
* '''"sql"''' for things relating to our sql data model.
* "video" for things relating to the video media type
+
* '''"video"''' for things relating to the video media type
* "audio" for things relating to the audio media type
+
* '''"audio"''' for things relating to the audio media type
 +
 
 +
* '''"test"''' for bugs that need some kind of test created in some way?
  
 
=== See also ===
 
=== See also ===
 
* [[BugTriageDay]] — every other Thursday
 
* [[BugTriageDay]] — every other Thursday
 
* [[TriageWorkflow]] — for discussion
 
* [[TriageWorkflow]] — for discussion

Revision as of 16:10, 16 October 2014

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" for bugs that need some kind of test created in some way?

See also

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox