We delivered eight (8) UX regression fixes, in 2.344, with more to
come in 2.345. I would like to personally thank everyone who
contributed to this concerted effort, including
- Alexander Brandes
- Feng-Yi Xue
- Jan Faracik
- Tim Jacomb
- Yu-Xun Chen
- Zbynek Konecny
Your contributions are highly appreciated, and they put us firmly on
the path toward delivering a stable LTS release.
This dashboard is very helpful. My understanding is that for a ticket
to appear on this dashboard, it must first be triaged. Over the past
few weeks, I (along with Adrien Lecharpentier) have spent a
significant amount of time triaging incoming UX issues. Roughly
speaking, my process is as follows:
- Reproduce the issue on my local machine.
- Find a recent release where the problem cannot be reproduced.
- Run "git bisect" to find the commit that introduced the regression.
- Update the issue with a "Caused By" link and notify the author on GitHub.
- Add the "(regression in 2.xyz
)" text to the title of the issue.
- Add the "ux" and "regression" labels to the issue.
While I have found a few ways to optimize the process, the process is
still very laborious and can take hours or even days if round-trip
communication with the issue reporter is required. While I am willing
to keep helping out as we get closer to the LTS release, I do not
think I can sustain this level of involvement indefinitely, especially
after the LTS release is shipped. Yet untriaged UX tickets continue to
come in every week, and past experience predicts that the volume of
tickets will only increase after the LTS release is shipped. Therefore
I think we should create a process that allows others to work on issue
Allow me to propose that we define a label, say "ux-untriaged", that
indicates a need for someone to take the steps I described above. This
could be added to the dashboard mentioned above in a separate panel
alongside the confirmed regressions. As issues are triaged, they would
either move to the confirmed regressions panel or disappear from the
dashboard entirely if deemed invalid.
I would be happy to conduct a session where I demonstrate the process
I have been using and explain how to do a "git bisect" efficiently if
anyone is interested. What do you all think?