Something new was tried in the hopes it'd be good, it turned out not to be
good, it was reverted, and now there's some discussion about how to make it
better. That's a successful process, not an unsuccessful one.
Given that this exact method of doing things is not only well-established
on the English Wikipedia but is also a recommended pattern (
bold-revert-discuss <https://en.wikipedia.org/wiki/Wikipedia:BRD>), I'm not
sure why you think this would be unacceptable there.
Dan
On Fri, 18 Jan 2019 at 22:13, Pine W <wiki.pine(a)gmail.com> wrote:
I'm glad that this problematic change to
communications was reverted.
I would like to suggest that this is the type of change that, when being
planned, should get a design review from a third party before coding
starts, should go through at least one RFC before coding starts, and be
widely communicated before coding starts and again a week or two before
deployment. Involving TechCom might also be appropriate. It appears that
none of those happened here. In terms of process this situation looks to me
like it's inexcusable.
In the English Wikipedia community, doing something like this would have a
reasonable likelihood of costing an administrator their tools, and I hope
that a similar degree of accountability is enforced in the engineering
community. In particular, I expect engineering supervisors to follow
established technical processes for changes that impact others' workflows,
and if they decide to skip those processes without a compelling reason
(such as a site stability problem) then I hope that they will be held
accountable. Again, from my perspective, the failure to follow process here
is inexcusable.
Pine
(
https://meta.wikimedia.org/wiki/User:Pine )
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l