Feature plugins appeared in the wake of the 3.6 release cycle, in which two large efforts were reverted before the final release: a UI for content using post formats and a refreshed aesthetic for the admin, notably with a new set of icons. Both suffered from the same problem: attempting to create and iterate on a significant feature within a single release cycle. The identification of that problem led to the idea of developing features as plugins, decoupling them from the time restrictions of fairly quick release cycles.
(While post formats had further issues that led to changes not landing in core, the admin design changes became known as MP6, a feature plugin which was merged in WordPress 3.8.)
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.
So, what’s next?
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.
To start, there is now a feature projects overview (still in progress) that is more of a higher level overview than the current status dashboard, with listings of feature projects that are in progress or merged, with sections for wishful thinking and projects that have been abandoned for one reason or another to be added in the future. Each project should be accompanied by a brief statement that clearly states what problem the project is solving, its goals, and how it supports the various philosophies and objectives of the WordPress project. The overview will also serve as a sort of roadmap for potential project features, albeit one without promises of delivery timeframes.
The general goal of this shift in framing and process is for feature development to be successful and lead to a stronger product with more contributors. Some individual goals in support of this are:
- Attracting and retaining a greater range of skill sets in contributors, for example through being able to more thoroughly engage designers in early stages.
- Implementing methods of collecting usage information and other data (more on that coming soon).
- Supporting feature projects with resources for user testing and more structured feedback.
- Advance both contributor and general community knowledge around product design and development.
Life cycle of a feature project
Today, feature plugins move forward in varying directions, frequently without a clear goal or target. This can make it hard to determine what their status is or what next steps might be. Learning from the current situation, feature projects will have clearer check points. For one, there will be bi-weekly meetings where anyone can propose a feature project, check in at specific goal points, update the community on the current status of a feature project, and/or ask for help if they’re having issues advancing their idea. We will kick these off in the #core channel in Slack on April 5 17:00 UTC.
Beyond this, there are several parts in the life of a feature project.
First, a feature project should have a brief statement of purpose. Explaining why a feature project is important to WordPress – and how it fits in with the values and philosophies of WordPress – is a necessary part for success. Without such a statement, projects can (and do) get “lost” along the way, ultimately heading in a direction that is not right for core, or start off on the wrong foot entirely.
This statement of purpose should outline the justification/explanation for why the feature project should exist. This statement is not meant to be encapsulate the entire idea, but should give an idea of how the idea fits into core and its concepts. Keep in mind that a simple statement is better than a long one; comprehensive statements may be all-inclusive, but they narrow the focus in a way that might not make sense as ideas morph based on feedback.
Here are some examples of previous feature ideas – since implemented – in the form of a brief statement:
- MP6: Simplify and modernize the design of the admin, with a focus on the rapidly growing user base using HiDPI, touch, and small-screened devices.
- Widgets Customizer: Improve the WYSIWYG experience of widgets through non-destructive live previews. The current approach of making some changes immediately live but not others breaks users’ expectations and trust.
After creating and proposing a project with statement at a meeting, ideas should move through a discovery and design process (more on that below).
Once the discovery results have been put together and published, it will be proposed to the core team as an official feature project during a regularly scheduled meeting. The core team then has the opportunity to study the direction before giving it the green light to move into implementation. It’s important to question ideas and assumptions early on to ensure the design and discovery process went well and that the project heads along the best path.
Next, with the endorsement of the core team, development of the feature project can begin. Development may take the form of a plugin, a patch on a core ticket, or whatever way works best for the specific feature project.
Finally, once a feature project is fully developed, it can be proposed for inclusion in core. Proposals can take the form of a Make/Core post along the same lines as feature plugin merge proposals, or by raising the specific ticket at a weekly core devchat. As the project gets closer to the finish line, it’s recommended that the team report on its status at one of the scheduled feature project chats.
Throughout the entire process, the feature project team should hold weekly meetings, allowing others to ask questions, gather feedback, and help develop the feature.
Discovery and Design First
WordPress has always taken a user-first approach to features and often even the APIs that power these features. The benefits of this approach show in adoption and the myriad creative ways developers have found to push its limits. In the past, the project has spent time testing features after they were developed, helping determine if the features were ready for core. However, as we find in product companies and digital agencies, design (interaction, visual, etc.) should be based on data gathered from discovery with real users and happen before design and technical implementation begin.
Feature design and development should come from interviews with users, developed personas, surveys of those personas, documented flows, and other fairly standard methods. Proper discovery will allow for testing long before functional development begins using low-fidelity storyboards and walking through potential concepts with users, both verbally and visually. Projects should check in at a meeting when discovery results are available and continue to check in through the design process.
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.
Feature plugins as a concept were a great idea; decoupling features from the release process gives us a lot of room to get things right. Adjusting our approach to cover all features – and to focus on discovery and design first – will give us a better WordPress.