This page describes how certain bugzilla features are used in Telepathy. It assumes that you are already familiar with bugzilla.
Keywords are pre-defined terms that can be added as tags on bugs. A full list of available keywords can be seen here.
In Telepathy we mostly use the following ones:
patch: The report has a valid patch attached
love: The report is something that a beginner could pick up and do on his own with little to no help. This should only be set by a maintainer or people familiar with the code base, and only when it looks like a project suitable for a new developer looking for a task.
security: Security-sensitive bugs
On the list of keywords that we do not use is the
NEEDINFO keyword. This is dealt with the
NEEDINFO status instead.
Please, do use keywords when appropriate, as it helps sorting out the bugs.
The whiteboard allows free-form text to be inserted, which shows up in the bug lists and can be useful for some additional sorting. Since adding new keywords requires filing a freedesktop sysadmin request, this is the best way to use custom keywords.
Some known whiteboard keywords that we use:
review-: Indicating that a patch (bug should also have the
patchkeyword) has been reviewed and is either deemed ok for commit (+ sign) or it needs more work (- sign)
- a version number: Means that the bug should be fixed in this version. This is used instead of the Version / Target Milestone fields of bugzilla, as editing them also requires sysadmin tickets…
Personal tags are free-form text, just like the Whiteboard, with the difference that only you can see them. They are stored per-user, so two different users can have different text written in this field. It is advised that you make use of them when you triage bugs to remember things without writing them on public visible fields (or on some notebook on your desk).
Please remember, though, not to put information that should be public in these fields. Do communicate information that others may also need.
Importance (Priority / Severity)
Priority and Severity are two fields that are often confused (even I confused them while writing this document…!). Here is what they mean:
- Priority: This indicates how soon a bug should be fixed. Bugs with high priority should be addressed sooner than bugs with normal or low priority.
- Severity: How important it is to address a certain bug or feature request. Even if something is highly important, though, it doesn’t necessarily mean that it should be fixed asap.
In order to avoid confusion as to what the scale is on these values, here is a table with reference meanings:
|highest||something that needs to be addressed asap|
|high||something that needs to be addressed soon, but not necessarily asap|
|low||something that can be left for a while later|
|lowest||something that will most likely never be fixed|
|blocker||we can't release the next version until this bug is fixed|
|critical||a problem or a needed feature that has a big impact to users, however, it will not block the next release if it's not ready|
|major||an important problem or feature|
|minor||not very important stuff, but we might want to keep them in the loop|
|trivial||an unimportant bug that is probably easily fixable|
|enhancement||feature requests that are not very interesting for us at the moment, but we could consider patches for them at some point|