Confirmed users
2,197
edits
Performance/Triage: Difference between revisions
Jump to navigation
Jump to search
→Triage Process
| Line 149: | Line 149: | ||
= Triage Process = | = Triage Process = | ||
== Introduction == | |||
The goal of performance triage is to identify the extent to which bugs impact the performance of our products, and to move these bugs towards an actionable state. The goal is not to diagnose or fix bugs during triage. We triage bugs that have been nominated for triage and bugs in the Core::Performance component that do not have the performance project flag set. | |||
During triage we may do any/all of the following: | |||
* | * Request further information from the reporter (such as a profile) | ||
* | * Set the performance project flag | ||
* | * Add performance keywords | ||
* | * Move the bug to a more appropriate component | ||
[https:// | == Who is responsible for triage? == | ||
Everyone is welcome to take part in triage. By default, everyone on the performance team is enrolled, but we also have participants from outside the team. The sheriffs are allocated on a weekly basis by [https://github.com/mozilla/perf-triage/blob/main/rotation.py this script] and the current/next week’s rotation is published [https://mozilla.github.io/perf-triage/ here]. | |||
== How do I schedule a triage meeting? == | |||
If you are on triage duty, you will receive an invitation as a reminder to schedule the triage meeting on the [https://calendar.google.com/calendar/u/0?cid=bW96aWxsYS5jb21fOWJrNWYycnFkZXVpcDM4amJlbGQ4NGtwcWNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ shared performance calendar] with the nominated sheriffs invited at a time that works for them. The responsibility of scheduling the meeting falls to the lead sheriff. Once a triage meeting has been scheduled, it’s a good idea to remove the reminder event from the calendar to avoid confusion. It’s a good idea to use the shared calendar, as this increases the visibility of the performance triage and allows other members of the team to contribute or observe the process. | |||
== What if a sheriff is unavailable? == | |||
The rotation script is not perfect, and doesn’t know when people are on PTO or otherwise unavailable. If the lead sheriff is available, it is their responsibility to either schedule the triage with the remaining available sheriff or to identify a suitable substitute for the unavailable sheriff(s). If the lead sheriff is unavailable, this responsibility passes onto the remaining available sheriffs. | |||
== How do I run a triage meeting? == | |||
The following describes the triage process to follow during the meeting: | |||
# Ask if others would prefer you to share your screen. This can be especially helpful for those new to triage. | |||
# Open the [[#Performance triage|first triage query]] to show bugs nominated for triage or in the Core::Performance component without the performance project flag set. The bugs are sorted from oldest to newest. For each bug in the list, follow these steps: | |||
#* For defects: Determine if the bug is reproducible and actionable. If not, add a needinfo for the reporter asking for more information and move onto the next bug. We have a [[#New bug|template]] that you can modify as needed. | |||
#* For all bugs (including enhancements): | |||
#** Set the [[#How do I determine the performance project flag?|performance project flag]]. | |||
#** Add the appropriate performance keywords. | |||
#** Move the bug to the correct bugzilla component. | |||
# Open the [[#Performance triage (pending needinfo)|second triage query]] to show bugs that have open needinfo requests. The bugs are sorted from oldest to newest. For each bug in the list, follow these steps: | |||
#* If the needinfo was set less than 2 weeks ago, move onto the next bug. | |||
#* If the needinfo was set more than 2 weeks ago but less than 2 months ago, consider adding a needinfo for either: another reporter of the issue, someone with access to the appropriate platform(s) to attempt to reproduce the issue, or a relevant subject matter expert. | |||
#* If the open needinfo was set more than 2 months ago, close the bug as inactive. You can modify the [[#No response from reporter|inactive bug template]] as needed. | |||
# If time permits, open the [[#Recently opened bugs with performance keywords in the summary|third triage query]] to show recently opened bugs with performance related keywords in the summary. If any of these look like performance bugs, they can either be triaged the same way as bugs in the initial query or they can be [[#Bugzilla|nominated for triage]] in a subsequent meeting. | |||
== How do I determine the performance project flag? == | |||
The [[../Bugzilla#Project Flag|performance project flag]] is used to indicate a bug’s relationship to the performance of our products. It can be applied to all bugs, and not only defects. The [https://codepen.io/mstange/pen/eYeWrGr triage calculator] should be used to help determine the most appropriate value for this flag. In addition to setting the performance project flag, make sure to use the “Copy Bugzilla Comment” button and paste this as a comment on the bug. | |||
== How do I determine the performance keywords? == | |||
There are several [[../Bugzilla#Keywords|performance related keywords]], which can be helpful to understand how our performance issues are distributed, or whenever there’s a concerted effort to improve a particular aspect of our products. The [https://codepen.io/mstange/pen/eYeWrGr triage calculator] may recommend keywords to set, and by typing “perf:” in the keywords field in bugzilla, you will see the available options. Select all that apply to the bug. | |||
== How do I determine the correct bugzilla component? == | |||
{{todo|}} | |||
= Templates = | = Templates = | ||