128
edits
QA/Bug Triage Guidelines: Difference between revisions
Jump to navigation
Jump to search
→Lessons Learned
No edit summary |
|||
| Line 325: | Line 325: | ||
Please '''REMEMBER''' that in order to return to the normal internet bandwidth speed, you will always need to reset all the limitations from the "refresh" like button from the software toolbar after testing, otherwise the limitation will remain always ON. | Please '''REMEMBER''' that in order to return to the normal internet bandwidth speed, you will always need to reset all the limitations from the "refresh" like button from the software toolbar after testing, otherwise the limitation will remain always ON. | ||
|- | |||
| General Bug Triage process || - Close the NeedInfo bugs for which the reporter has not come back with a reply within 2 weeks (previous period was 1 month) | |||
- Don’t use the ‘Reporter’ expression inside bugs when you’re addressing him/her. Instead, try using his/her name or Bugzilla username. (applicable for reporters with an intelligible name/email address) The desire here is to make the communication more personal. You can still use ‘reporter’ word inside comments when you’re not directly addressing him. | |||
- If a certain developer has started working on an untriaged bug (has relevant comments inside it, changed bug’s status…) and we’re not very sure to what component to assign this bug to, first expected action would be to ask directly the developer for it (either he tells you the component or set it himself). Just in case you’re not receiving any reply from the developer, it’s ok to bring this bug into Ryan’s attention. | |||
- For old bugs (ex: 3.2k list ones) – if the bug still reproduces and we consider it a high impact – it is ok to set comments for it. If the bug still reproduces but is lower severity, we should not add new comments to it (just change the status if case requires it). This change has come as a complain from several developers that they’re getting spammed with bug triage work for not so relevant bugs. | |||
If the low severity reproducible bug has by any chance Priority P1, we should decrease it. Applicable only if P1 has been set by the reporter. (if it has been set by dev or somebody else from Mozilla, please leave it as is) | |||
If the bug is a web compatibility one and we’re not being able to reproduce it on Chrome, then it’s ok to set a comment for it (even though it might have a lower severity). | |||
- take enough time to try to reproduce the bug and only when we could not reproduce it or don’t have enough info to reproduce it, then ask the reporter to try other cases. We should explain the reporter what we have tried, on what version of Firefox we tried to reproduce and then ask for more information if we cannot reproduce the bug (or ask him to try to reproduce the bug in safe mode or with clean profile). | |||
|} | |} | ||