If you’re like me, you really love WordPress but you often ponder what it could be like if it just had a few more features built-in. How much easier your life would be if – for example – it had robust user editing features, or post type and fields generation, or several other things that you typically install and configure plugins for.
If you’re like me, when you start pondering like that you might turn to Twitter and share your thoughts and see if others have similar feelings. That’s where this reflection starts:
Sure enough, quite a few folks have their laundry list of desires and wishes for WordPress Core too! For some it was multi-lingual support, a centralized notification system, a way to support paid plugins officially, media library love, and a smattering of other really significant features.
For some of these things, there’s hopes. We already know that multi-lingual support will in fact be coming to WordPress Core around 2024. And there is a Notifications API feature plugin and project that is actively being developed but no official plans for inclusion to date.
But for many of these, they continue to be really good ideas that will just continue as “plugin territory”.
I also asked the Advanced WordPress Facebook group about this. A similar conversation happened there, with many echoing my list or adding to it. Some took issue with how everything related to Gutenberg seems to have hijacked all the Core attention away from these priorities to making WP a page builder to compete with Wix or Squarespace.
There seems to be a disparity between what the WordPress Core leadership is building and what we want WordPress to be. Share on XThe whole conversation got me really thinking about the roadmap for WordPress and how we all seem to have very different priorities than the Core leadership of WordPress does. And also how we at GiveWP have been working to address this concern with our users and customers as well.
The Need for a Public Feedback Channel
My partner Devin Walker and I, long ago, got tired of pushing really fun and exciting releases and then getting emails from users saying “Cool, but when are you going to do X instead!?” It’s just not fun to get that kind of feedback. On the other hand, it’s less fun to be a user seeing big releases go out that do not address your primary concerns in any way.
So how do you bridge that disparity of expectations from a business/product perspective? We worked with our team on the best way to receive public input and feedback and prioritize that feedback into actionable development roadmapping.
For us, the process started with a tool called Canny.io. It’s a simple way for users to post their feedback or feature requests and for others to upvote that feedback.
But such a system isn’t a “if you build it they will come” kind of scenario. After we launched it, we had to continually encourage users to use it. We have really excellent Technical Support and Customer Success teams who daily encourage users to use Canny.
Now after several years of doing this, we have over 3200 users with over 10,000 votes and comments across four different public project boards.
I can’t overstate it enough: The ability for users to actively inform your roadmap changes the whole dynamic between creator and customer for the better.
This is one thing I believe the WordPress project is desperately missing today. Yes, people express their opinions in many, many places about WordPress features and product development. But the breadth and chaos of the feedback is exactly part of the problem. How can leadership plan with user intent in mind when the chaos of the user-base is so erratic and loud?
Yes there is WordPress Slack. But the reason you have a public feedback board like Canny is to get out of your own echo-chamber. When it comes to product feedback, Slack is an echo-chamber, not particularly useful for actual user input and feedback.
Yes there is Github, but when it comes to WordPress Core, the readme specifically says to go to SVN instead. SVN!? That’s not how to encourage feedback — that’s a tool for insiders who code. Gutenberg is also hosted on Github and gets input there, but that is not representative of the whole project and the feedback there is focused on features of Gutenberg specifically.
UPDATE: It was pointed out to me that there is a public .org forum for feature requests. This shows the desire for a centralized place for public feedback from the .org volunteers — which is nice. But for a public feedback board like this to work, it needs to be managed by the decision-makers, not the .org volunteers. Additionally, it needs a voting system so the best ideas can bubble to the top. Lastly, when feedback gets a lot of votes, leadership has to take that seriously and either explain why it won’t be a priority or add it publicly to the roadmap. None of those things seem to be the case with this forum currently.
Having a system, any centralized system, where general product feedback goes and can be voted on by the wider public and is acted on is crucial to a truly public open source project – particularly one that so many people all over the world depend on.
Transparency in Leadership
There’s another side of me that also knows that at the end of the day, Devin and I determine the roadmap for GiveWP. Whenever I hear folks complain about Automattic and that they are doing whatever they want with WordPress, I say: “Well, I can tell you as a product owner that if a million people wanted us to add a Shipping feature to GiveWP we still wouldn’t do it.”
We own the roadmap, it’s ours to dictate. Same for Mullenweg.
But, in order for the community disparity to be bridged, we not only have our public feedback channel and make sure that feedback is acted on, we also communicate regularly, publicly, and transparently about what we are working on.
Currently, Mullenweg has been very clear about WordPress’ primary roadmap, it’s publicly available. And honestly, this is the most detailed roadmap I’ve seen from the WordPress project in quite a while. But it’s very incomplete. For example, the Notifications API project. We know it’s a “feature plugin” – where might it fit in this roadmap if at all?
There’s also not a lot of validation of these ideas in this roadmap. For example, how did the idea of a more intuitive way to collaborate on content become a big feature to be tackled? Without a public feedback board, that feature – while interesting and potentially valuable – feels like it’s getting pushed to the front of the line making the community kind of turn their heads in confusion.
The Elephant in the Room: WordPress.com
One big reason for the disparity between the community laundry list and what is actually being roadmapped is quite obvious to most who monitor the project closely. Mullenweg is accountable to keep his company profitable, and one of the most important revenue streams depends 100% on the success of WordPress; namely WordPress.com.
This is not a secret nor a surprise, and honestly I don’t believe it needs to be a “problem” either. If dynamic collaboration (as an example) is a feature that WordPress.com needs to be successful, be transparent about that from the .com website. Talk very publicly about what the .com priorities and future are all about and why and how it’s being positioned to win more customers. Most reasonable people appreciate transparency, even if they wish you had different priorities at least they’ll understand and perhaps even sympathize.
Where does this leave us?
With all that in mind, what do we as WordPress users, creators, businesses, and fans do about this disparity?
We keep pressing publish. We keep creating, we keep innovating. Yes I wish I didn’t have to install and configure User Role Editor, CPT UI, and ACF or Carbon Fields in every single website I install. But I sure am glad those plugin authors keep fighting the good fight and providing me with great value.
As a community, we keep creating and innovating and that fills the disparity gap in and of itself.
All sounds good with one exception: What is WordPress? Is it just core, or is it core themes plugins? I’d definitely go for the latter.
Perhaps many people don’t realize that, but the WordPress core is just the beginning. You cannot discount the plugins and themes that let everybody do what they want and need with WordPress. Is having to add features you want by installing plugins so bad? Should core try to be “everything for everyone”? Not so sure that’d be better.
Good thoughts. My argument here was intentionally limited to conversations around WordPress Core, which does include some default themes and a plugin (albeit an extremely simple one!)
I definitely don’t believe Core should have all the features for all kinds of websites, and the line there is a slippery slope for sure. But the features I mentioned above are — in my experience — part and parcel to working with every WordPress website and therefore worth discussion around Core inclusion.
There are plugins for those things for sure, but each requires installation and configuration. Being included in Core would give them priority status, which I believe they deserve — particularly user management, fields management.
Thanks for reading and chiming in!
Matt, Very well stated. I enjoyed reading and hearing your thoughts.
I agree a public way for feedback would be great.
Thanks Christopher! Thanks for reaching and chiming in!
Post has many point to discuss.
> Talk very publicly about what the .com priorities and future are all about and why and how it’s being positioned to win more customers.
This!
Gutemberg and FSE are clearly a .com project and i understand, they put the money to develop and they can what they want with them. Problem is when the force feed us with that half baked solution.
I also think WP as it s has huge holes: The above mentioned
“Centralized Email Notifications Management Global settings for common APIs like Maps, FB app, Stripe/PayPal”
and let me add a proper Multilanguage CMS are super important and urgent.
i also love CPT e Fields, but i understand not so much people will need it. for sure it would good to standardize them in a way
Definitely a multilingual solution is much more urgent than a CPT and fields one, because you already have CPT and custom fields built into WordPress, and several different plugins tap into this features, and handle them natively.
Multilingual, on the other hand, is handled in various ways, some tap into native infra-structure, some don’t. Theoretically, I believe multi-site is a smart approach to multi-language, and some plugins have used this approach, like MultilingualPress or Multisite Language Switcher. This is a very different approach of that from WPML or Polylang.
Maybe this could be the fastest way to implement multilingual as a native feature of WordPress, since multi-site is already a native feature. you’d just need a way to connect 2 or more different language posts (and other data, like taxonomies), each created and edited in its own “network” site. And then let plugins solve the specifics, like shared stock for stores, for example.