Before you immediately click away, I want to state that this post is not about politics! I want to talk about some of the ideological decisions of the WordPress project and their impact on development. This is about data and decisions, and about where the former is missing to inform the latter.
While I’m currently trying to get more involved in contributing to the Core component that makes up WordPress, the system I chose to work with, I feel like seeing a recurring pattern whenever there’s a push for progress. The people in favour of this progress are seen as the “minority” that does not want to acknowledge what the actual “majority” wants or needs. On the other side, we have people who stand up for this “majority” and try to defend its position and generally act in its best interest.
The problem with this is that any knowledge about this “majority” is mostly just subjective opinion that can neither be verified nor refuted. So, in my eyes, this situation then boils down to one vocal group trying to question the status quo, and their arguments being actually vetoed by the opposing vocal group using a “majority” assertion that simply cannot be argued about. This is frustrating for both groups, as the first just feels ignored, and the second will need to re-discuss this topic again and again. The discussion itself will just continue endlessly or slowly fade and dissolve.
There needs to be a way to resolve such discussions with meaningful data and solid assertions.
The WordPress Philosophy
Here’s an excerpt from the WordPress Philosophy:
Design for the Majority
Many end users of WordPress are non-technically minded. They don’t know what AJAX is, nor do they care about which version of PHP they are using. The average WordPress user simply wants to be able to write without problems or interruption. These are the users that we design the software for as they are ultimately the ones who are going to spend the most time using it for what it was built for.
Here’s another one:
Clean, Lean, and Mean
The core of WordPress will always provide a solid array of basic features. It’s designed to be lean and fast and will always stay that way. We are constantly asked “when will X feature be built” or “why isn’t X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.
These principles seem to indicate that all design decisions are ultimately run by the user base to get a kind of “democratic” voting of what changes to implement or reject. However, the reality is far from that. End users are “belittled” and only a select group of people gets to define what the “majority” actually wants.
There’s also the often referenced mission of WordPress to “democratize publishing”, although this seems to originate from the WordPress.com platform (although both the wordpressfoundation.org site and several make.wordpress.org posts seem to indicate that WordPress.org has accepted this mission as well).
Of Wants And Needs
My own personal opinion is that most of the time, users (as well as voters) do not really know what is best for them. What they want is not what they need. They are easily manipulated to choose whatever option seems popular, and they don’t have the necessary contextual knowledge to reason about the consequences of their voting.
Still, I do think that the current situation needs to be addressed, by:
1.) either accepting the democratic notion and introducing a way for users to be included in decision-making;
2) or accepting that there is a need for long-term vision and leadership and providing a process for discussions like the above to be reasonably concluded.
So, either we go with 1.) and we need to have data about the “majority” that is used as an argument, or we go with 2.) and the “majority” has to be dropped as an argument altogether. I would prefer someone telling me “No, we won’t do this, we decided we just don’t want to.“, rather than coming up with a bogus assertion that just leaves the discussion unresolved. That’s not a productive use of anyone’s time.
To this end, I have submitted a new Trac ticket in the hopes we can discuss the merits of directly letting users impact decisions. The goal is to turn the unverifiable “majority” argument into a valid assertion backed by data.
I personally would still prefer option 2.) above, as I think it would provide more focused and effective progress, but I strongly doubt that the community can agree on this if we don’t even have the tools for 1.) yet.
Now, Where Did That Come From?
The impulse to create this ticket was the result of a discussion about introducing an autoloading mechanism into WordPress Core. This is a hotly debated topic, and some of the arguments were along the lines of “People using XYZ are the minority”, “This is an edge case”, etc…
As I cannot directly speak on behalf of the “majority”, I launched a Twitter poll to collect data:
Do you want an Autoloader in #WordPress Core?
— Alain Schlesser (@schlessera) September 6, 2016
Of course, when I posted this data, it was quickly dismissed as not being representative and not having a large enough sample size, and rightfully so!
However, there’s currently no way I’m aware of to get better data on such topics that would be statistically conclusive. That’s why I think there’s something missing here.
What do you say? Did I drink the wrong coffee this morning, or are there other people who feel the same way? Let me know in the comments below either way!