Hi!
On Fri, Jan 18, 2019 at 10:13 PM 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
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,
--
Stas Malyshev
smalyshev(a)wikimedia.org