The WebGL team receives many bug reports from users of Chrome, and web developers in particular. In order to maintain a high quality product, and enable customers to deploy successful 3D web applications, it's important that these reports be evaluated in a timely manner.
In order to better scale the team's efforts, a bug triage rotation has been introduced. The specifics of the rotation follow:
Each rotation is one week long.
The current triager is responsible for:
Monitoring the incoming new bugs to the Blink>WebGL component, per the following query:
If the query above doesn‘t turn up anything, it’s possible that the bug was already moved into a different state by the GPU triage rotation. In this case please look into the following queries. Please note that these will turn up much larger lists, so only focus on the new bugs.
Please also monitor these candidates for closing as WontFix:
If an issue interacts with other components, add those components. (e.g. V8 via Blink>JavaScript or sub-components, media usually via Internals>GPU>Video or Internals>Media>Video)
Determining on what graphics hardware the bug occurs, and assigning GPU- and OS- labels.
Reproducing these bugs, as best as possible, given the graphics hardware at the team's disposal.
Figuring out whether it's a bug in the application, and, if so, closing the bug with an explanation.
Figuring out whether the bug is a regression. If it‘s appropriate to ask the submitter to run a bisect, please do so; if it would be easy for Chrome’s Test Engineering team to run it, add the Needs-Bisect label; or run a per-revision bisect (Google internal, sorry) manually.
If the Summary is undescriptive or imprecise, rewriting it.
Determining a Type and Priority for the bug, and assigning ReleaseBlock-(Stable/Beta/Dev) if appropriate.
Working with the submitter to produce a reduced test case if at all possible, and, if so, integrating that test into the WebGL conformance suite. Add the Needs-Feedback label as appropriate to remove the bug from the queries above.
Marking the bug as duplicate if necessary.
Finding potentially-related bugs and recent changes, adding Blocking/Blocked-on links.
Assigning to the owner of a likely-related bug or recent change.
Prefer to use the “Available” state to indicate that a bug‘s been triaged, rather than assigning bugs to yourself, to avoid having a big bug backlog. For any new bug that’s not related to a recent or existing issue, there should be no owner.
It‘s the triager’s responsibility to do the above steps for all of the incoming bugs during that shift. Bugs that aren‘t handled during a given shift stay with the triager; they don’t spill over to the next shift, unless there's agreement with the person next on the triage rotation.
This is intended to be a lightweight rotation that shouldn‘t take too much of the triager’s time. For this reason it's scheduled independently of other shifts like pixel wrangling, and may overlap. If any conflicts do arise, please reach out or swap shifts.
The rotation is managed in rota-ng. The rotation members, as well as a few others, are owners under their @google.com addresses.