On WordPress And Democracy
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.
Ideological Nonsense?
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!
One thing that leaps out at me is that the word ‘users’ is very problematic when trying to decide whether a feature like an autoloader should be included in core. In this case, the group of people who should be deciding this issue are people who use WordPress as a framework – eg, developers.
In scrum there’s the concept of the product owner, and also the system product owner. I am the system product owner for our WordPress project and as such I can insert stories into a sprint that have to do with strictly technical matters, such as to get automated testing running under Behat, for example. Our product owner would never represent that viewpoint and those needed stories would never get done if I didn’t have equal standing in the project as system product owner.
I think this concept could be usefully applied to WordPress core if it is not already. Call it whatever you want, an ombudsman for developers, or the DUX lead, or whatever, but it would be good if there were someone who has standing in the project and who takes as their own the responsibility of leading DUX issues and ensuring that needed improvements for developers are made.
Data could be helpful for this person but without that leadership, it is unlikely that any real progress will be made for developers.Report
Hey Lisa,
Yes, I completely agree that not all users are equal. That’s why I propose to have the users opt-in to such a system by selecting what contribution areas (as they are identified at https://make.wordpress.org/ ) they are interested in. This way, only developers would opt-in to the “Core” contribution area, for example.
Leadership is needed in any project, so I just assume that this is one additional tool that would make leadership less painful, not replace it entirely.
Thanks for chiming in!Report
You really dont want me comment on this.Report