I’ve been looking forward to a post like this. Helen Hou-Sandí has written about an evolution of the feature plugin model.
Over the last two and a half years, we’ve had successful feature plugins that were merged into core, efforts that began small and grew as discovery happened, ideas that never quite got off the ground, and ideas that were initially explored in “plugin” form but ultimately became patches for various reasons, usually technical. With over two years of active feature plugins behind us, it’s time to take a look at what’s been successful, what hasn’t been, and where we go from here.
Indeed, it’s always been a bit confusing on where to draw the lines on what makes a feature plugin. I have always loved the idea, but as Helen mentions, its shortcomings have come forward after enough tries at it. There have been a few dozen (at least) starts on feature plugins, and 17 or 18 that have landed in core.
Thinking of features as plugins has strapped us in a number of ways, in large part because the “plugin” part implies a functional project from the start. From observation, experienced and newer contributors alike set their initial goal to be some sort of functional plugin. As a result, by the time something is being proposed in whatever forum, there’s been a fair amount of effort spent – and personal attachment developed – for something that might be headed in the wrong direction. Changing direction at that point is very demoralizing and has led to burn out and less participation.
My suggestion is to move both nomenclature and mindset to “feature projects.”
Feature projects are similar to feature plugins in many ways (including in name), but may not take the form of a plugin; in fact, they likely will not begin as plugins. Most will start as ideas that need exploration to be more fully formed/fleshed out before implementation. Others will become discrete patches on tickets. Others may turn into multiple plugins, breaking out the successful parts of the project into patches for core, while iterating on the less-successful pieces. Still others may remain in plugin format even after reaching a polished point, as they may not make sense as a bundled part of core but serve a valuable purpose for users.
With a feature project mentality that is unrestricted by the plugin concept, Feature Projects can take on a more encompassing scope that starts with why and not with how. The projects will all now start with a brief, where the proposal presenter will begin by, “Explaining why a feature project is important to WordPress – and how it fits in with the values and philosophies of WordPress.” I think this will be a huge improvement.
This also brings design and discovery to the forefront — as a first class citizen for feature projects. Still, not everything started will be right for core, and as Helen says, that’s okay. I’d go farther and say it’s an intended goal as the discovery process helps refine the ideas, and sometimes purge those that just don’t pan out:
It’s important to note here that some discovery and design stages may be successful by most measures but not lead to a viable feature for core. This is okay. Going through these stages will often still lead to improvements that can be brought back to core and will help us refine feature project approaches in the future.
There are some feature “concepts” that I think can flourish under this new model. The REST API is obviously one, as the infrastructure is in but the “plugin” is not. The Fields API is another — as it has broadened in scope and may end up touching many parts of core. But others even more so: like the new user experience, which deserves a more encompassing project, and also what was termed “content blocks” way back — that is a form of modular content creation.
I think this evolution of thinking can go a long way, and also be a great way to re-engage folks that burned out isolated in never-ending plugin projects. It’s also an excellent way to get more non-developers involved early and often, hopefully even leading some of these projects to bring a broader base of experience and understanding, that will inevitably improve the WordPress project as a whole.
