I don't know if this already has a name, but I'm going to invent one: The Great Circle of Excuse. It works like this: we have all realized that something needs to be improved, let's say the design of our website. Then, WMF gets a group of workers to think about
it, and they come up with some changes that neither respond to the needs nor are really a change beyond certain aesthetic resources. It is always mentioned (excuse 1) that these changes have been measured externally (and, coincidentally, reinforce the design
made) and (excuse 2) that there are people who do not want any change, so it is better not to be radical and make a patch that, in reality, we all know that it does not solve anything.
Then a previous design is presented to the community and a lot of comments are collected. As the design is only partial (look, this is what the Moon article is going to look like
), and does not respond to all the other sections we have (home page, search pages, categories, menus...), you receive feedback that can be categorized into two main groups: the small group A tells
you not to change anything. The big group B tells you that it doesn't even scratch the surface of the necessary changes (https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Prototype_testing
You have a few outsiders who tell you: "well, this is better than nothing". At that point you decide that you have to weigh group A with group B, so your design is right in the middle of the will of the community, and you go ahead without making the slightest
change. Excuse 3 is set up: I heard the community and I'm weighing everyone's wishes. In reality, you only listen to your design and those outsiders who have told you it's better than nothing. The majority will continue to see that this is going nowhere and
a minority will continue to be angry that you have made changes when they don't think you should have.
After excuse 3, it's time to implement. You decide that this has to be done in a very long process, where you measure the impact of every little change, without taking into account that every little change break something that was already working. So,
you have trivial changes that break things, covered by excuse 4: we are measuring the impact. Even if the impact contradicts your assumption, the change will still be there (https://phabricator.wikimedia.org/T285755
Because, hey, who cares (excuse 4.1).
At this point in the circle, there is some volunteer who wants to fix this and raises the tone of the request. Then we find the mother of all excuses, the wild card: you are being rude and do not assume good faith. Excuse 6.
At this point a new figure appears: the direct meeting with the team that is developing this. The team wants to listen to you. Actually, it's the opposite: they want you to listen to the new excuses that exist in the circle. You go through excuses 3, 4
and 5 with them. As excuse 6 can no longer be used, because you are there volunteering your time to try to improve something, excuse 7 appears: we can't take on these changes because our team is small and we can't make the logical changes you are suggesting
for another 2 or 3 years. Maybe. If there are funds.
So the user who has gone through excuses 1, 2, 3, 4, 5x, 6 and 7 decides to write an email to the mailing list where the community will see that the problem is 7: there is not a big enough team to undertake something that we have decided in our strategic
discussion. In fact, we are going in the opposite direction of the strategic goals. But we have money. A lot of it. A lot of money. We are sitting on mountains of money. We could simply hire people so that we can improve our system so much that it works perfectly
for another decade and then, with minimal investment in staff, get a lot more money from people who like our service a lot more than they did before.
But no, instead we get excuse 8: there are actually enough staff, but those poor staff can't do what they should do, poor staff, because the community doesn't want change (excuse 2) and the environment is toxic (excuse 6). Or, as a variant: a bigger team
may not be better (despite the team says that they can't do it because their team is small). So, once the circle is closed, you go back to opening issues in Phabricator to try to improve these problems. Because it only takes one manager, someone who knows
how to manage a team, to realize that there is a problem here. And what do you find in Phabricator if you reopen issues? Surprise, you get back to box 5, in its variants a, b, c or d.
The circle is closed. No one is responsible for anything. No one can solve it. In the meantime, we have 100 million dollars, a flawed website, a make-up process that leads nowhere, whole communities with basic things broken for months and no prospect of
improvement for the people who, in good faith, try to help along the way. We lose readers. We lose volunteers. We lose time. We lose money. We lose everyone.