Hi!
On Fri, Jan 18, 2019 at 10:13 PM 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
I think there's no reason to make it bigger deal than it is. There was a feature that people thought would be good, turned out it is not as good as expected, so it was disabled. Nothing broken, nobody hurt (well, maybe except some inboxes...). I don't think there's a reason to describe this situation as "inexcusable". Sometimes something that we expect to work one way and be useful turns out different way and things that seemed to be excellent idea turn out to be very bad one. And we have to adjust, and this is normal. We don't like such situations, but we know they happen, and as long as they are handled properly - and I think in this case it was - there's no reason to make it more than it is.
reasonable likelihood of costing an administrator their tools, and I hope that a similar degree of accountability is enforced in the engineering
I hope not. Expecting unreasonable perfection from people and processes and overreacting when inevitable problems happen will only lead to frustration, failure and stagnation. Every failure has some lesson to learn, but the lesson shouldn't be "let's find somebody to punish". I am not sure if that was the intent, but it kinda felt this way to me. And I don't think this is warranted neither in general nor in particular case.
Thanks,