This is a draft of Bugzilla Workflow. This is not an actual policy.
Triage is basically asking user questions and "baking" bug so it looks yummy-yummy enough for developers to eat it. See more in #Bug Triage.
Your job, as a member of the Triage Team is to keep this list empty.
Put a question mark in the need_info flag. Optionally, put the reporter's email to show that you're needing info from him or her. This means that you have asked the reporter a question, and are waiting for their answer.
You forgot to put a question mark to the need_info flag.
Change the bug's component from "-Enter Bugs Here-" to the proper one. See #Bug Categories.
If you were personally involved in triage, then yes. You are automatically added to CC list, and unless you remove yourself, you'll receive messages. If you just received this via triage-desktop@ mailing list, then no.
Don't do anything. In particular, do not subscribe to triage-desktop@ mailing list. Subscribing to bugs@ will make you receive messages about triaged bugs only.
Change its component to "-Enter Bugs Here-".
First, check if the bug really needs triage. Maybe it was filed by a developer or tester of ROSA Desktop, who knows what information is necessary. Maybe it has already been triaged in helpdesk. If the bug really needs triage, change its component to "-Enter Bugs Here-".
They're triaged like all other bugs. However, the messages are sent to private-bugs@ mailing list rather than to the desktop-triage@. You will see them in the list of bugs awaiting triage, however, if you have enough permissions, with a lock sign nearby.
The policy listed here applies to the bugs filed against "Main Packages," "Contributed Packages," "Package Requests," components in "ROSA Desktop" product in ROSA Bugzilla. Other categories are free and encouraged to adopt this workflow, but this is not mandatory.
All bugs must be filed to "Enter Bugs Here" component. This component accumulates all untriaged bugs. Users are encouraged to enter complete, well-written bug reports, and the initial screen provides helpful tips for them. However, Triage team is to ensure that users enter complete information, and are familiar with the documentation that could help them in their case.
Several categories of people may also enter the bugs to other components, thus skipping the triage:
If the component has been chosen incorrectly, and the bug still needs more information, the assignee should reassign the component back to "Enter Bugs Here".
Bug triage should start no later than five days since the bug was filed (ensured by #Whining).
By Bug Triage we understand here collecting initial information about the bug. This information should be enough for a developer to realize what the problem really is. Here's the list of information that should be collected:
When bug triage is over, the triager sets the proper component, and bugzilla will change assignee and QA contact automatically. The bug will be handled to developers (see #Initial Resolution).
A triage, however may reveal some problems with the report:
Initial resolution applies to new bugs in "Main Packages," "Contributed Packages," and "Package Requests." components. status means the bug has been triaged, and there is no evidence that it can't be reproduced. At this point, a developer (or any other interested party) should try the bug, and resolve how important it is.
The initial analysis can lead to several results:
When the bug is confirmed, triaged, and its upstream status is unknown or our, the bug is handed to distribution maintainers/developers. Bugzilla front page will include a filter to show these bugs only, and hide unconfirmed, untriaged, and upstream bugs.
When a maintainer/developer decides to fix a bug, he or she does the following:
After the bug is fixed, it's marked as RESOLVED FIXED, and the update request is made in the very same bug as per Submission Policy.
If the bug that should be in another Product/Component, change it, as per #Bug Categories.
Aside from getting triaged, and then fixed, bug may have a less lucky destiny.
Anybody may perform attempt to reproduce the bug. This is not a mandatory step for triage. Contrary to usual understanding, it's not a necessary step, as even if the bug is reproduced, but of a low priority, it's no use of fixing it, hence the excessive reproduction is a waste.
When somebody reproduces the bug, they may leave a note about this. If the bug can't be reproduced, and more information from user is needed, you must:
If a bug can't be reproduced three months after this fact is detected, the bug may be closed with RESOLVED WORKSFORME status.
Sometimes—though 'very rarely—fixing the "bug" will violate our policies. This means that user expectations do not meet restrictions of our distribution. For example, it's easy to imagine that fixing a bug will require us to violate our own security-related policies.
In such sad cases, the bug should be closed as "RESOLVED WONTFIX". Please note that such resolution always originates from Technical Committee decision, which could be a policy or an explicit reasoning about this bug. The same "wontfix" status at upstream's side is not enough to mark the bug as wontfix in our tracker.
At any point, the bug can be closed as a DUPLICATE of another bug. Please, choose the bug with more advanced status to be the "main" bug, and close other bugs as duplicates of them. I.e., prefer triaged bugs to not triaged, the in-progress bugs to merely confirmed, and those with resolution to those without (even if you don't like the resolution).
When a bug has some information that could be used in documentation, you may request a flag "document", so the technical writers can easily select what to write about.
Bugs (and ticket in general) should be placed into proper categories. Here are some categories (the format is Product/Component):
The default QA contact and assignee for new untriaged bugs is triage-desktop@lists.rosalab.ru. Everybody who wants to participate in bug triaging should subscribe to this list, see ROSA Mailing Lists.
The bugs in other components, where the triaged bugs reside, will have bugs@lists.rosalab.ru as QA contact and assignee unless otherwise specified (Bugzilla will change it automatically from triage-desktop@lists.rosalab.ru). Subscribing to bugs@ list means that only triaged bugs will be received. Subscribe to both lists to get all mails from bugzilla.
By "ensured by whining" we mean that unless the specified action is taken in the specified amount of time, Bugzilla will automatically send e-mail about this to different persons involved. It starts with mailing to the responsible party, continues with rosa-devel@, and then proceeds to send mails to the ROSA management.
For instance, if bugs do not get triaged fast enough, it will send lists of such bugs to rosa-devel. Indeed, any developer is qualified enough to be a triager, and it's our collective responsibility to maintain our Bug tracker in a consistent state, so this notification will help us to improve our distribution overall.