On Mon, 12 Jul 2021 at 19:26, Tyler Cipriani <tcipriani(a)wikimedia.org>
(Late reply: I was out the week this was sent, then
another week of
* Can we do something to improve the speed from
"a user notices an issue
with the site" to "the right team/owner is aware of it and acts on it"?
Or can we do something to improve how many issues users notice? :)
As someone who's been around for a long time as an editor, I can say
honestly that having most of the issues addressed before they hit the
really big projects has resulted in a huge improvement. The train really
works, and the only challenge I really see is what Jon mentions in his
original post. Some of those issues aren't really that significant in the
great scheme of things, but there's a big leap when something takes two
business days to fix from the Tuesday deployment and two business days to
fix from the Thursday deployment.
It's not always possible for even the best developer and the best testing
systems to catch an issue that will be spotted by a hands-on user, several
of whom are much more familiar with the purpose, expected outcomes and
change impact on extensions than the people who have written them or QA'd
them. That's why there will always be plenty of issues that are identified
by users, and it is in no way a problem that a small number of them
(compared to what we saw 10-15 years ago) get through to the end of the
train before being identified as needing to be addressed (for different
values of "addressed").
Other people on this list are in a better position to understand the
implications of backporting on Fridays, but I think it would be worthwhile
to give serious consideration to expanding the list of what could be
included in a Friday backport. Limiting it to essentially "breaks the site"
or "major impact to accessibility of the content" doesn't really include
most of the noticeable user experience issues (for either editors or
readers), and leaving those sitting for a minimum of half a week is