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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l