Last year, I identified key factors that suggested the features-as-plugins first model was falling apart. A lack of communication, direction, buy-in from core developers, and synchronized development between plugins on Github and WordPress.org were some of the contributing factors highlighted.
Features-as-Projects
WordPress lead developer Helen Hou-Sandí has outlined a new strategy for the model transitioning from a features-as-plugins approach to features-as-projects.
“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,” Hou-Sandí said.
“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.”
A New Page for Featured Projects
Feature projects are listed on a new page which includes a brief explanation of the problems being solved. Active projects include WordPress NUX which aims to remove barriers to entry and Font Natively which switches to system fonts to load faster and provide a more native experience.
Anyone can suggest a feature project but its mission statement must clearly address what problem it’s trying to solve, its goals, and how it fits into WordPress’ core philosophies and objective. The new page also serves as a roadmap for future feature projects.
By changing their approach, the core team hopes to achieve the following individual goals.
- To attract and retain 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.
- Supporting feature projects with resources for user testing and more structured feedback.
- Advance both contributor and general community knowledge around product design and development.
Beginning Tuesday, April 5th, 2016 at 1PM Eastern Daylight Time, in the #core Slack channel, bi-weekly meetings will be held where people can propose and discuss feature projects. These meetings are also where project leaders can ask for help, provide status updates, and maintain direction.
Design and Discovery First
Perhaps one of the most important changes in the process is the focus on discovery and design first. Instead of testing features after they’re developed, this plan focuses on gathering testing and usage data from users before technical implementation occurs.
“Feature design and development should come from interviews with users, developed personas, surveys of those personas, documented flows, and other fairly standard methods,” Hou-Sandí said.
“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.”
Even though the discovery and design phase may not lead to a full-fledged feature in core, the process should help discover pain points along the way which can translate into other improvements.
Iterating is Not Just For Software
The new model incorporates many of the suggestions by WordPress lead developer, Ryan Boren from 2014.
- Be present and up-to-date in the plugin directory.
- Be as ready to go on mobile as they are on desktop.
- Have visual records for major flows through all new interfaces on all devices.
- Have mature UI that isn’t going to derail the release train.
- Have a history of posting weekly updates to make/core.
- Have a history of regular plugin directory updates.
- Have a testing audience.
- Publish a merge consideration post on make/core complete with visual records and other diligence.
- Exist for at least one release cycle. Plugins created at the beginning of a release cycle should not be considered for merge until the next release.
It also focuses on establishing a direction for a project early on instead of people aimlessly developing it to see where it goes. It’s worth noting that Boren supports the changes to the model.
Early feedback suggests this is a great move. Michelle Schulp, Founder of Marktime Media, had this to say about the changes:
Love this, not only because it a) treats WordPress more like an actual product where decisions on features should be tested and vetted before they’re built, and b) validates the design and discovery process as ‘important to WordPress’ and saves a ton of unnecessary dev time, but also c) will help encourage those with other important talents like design/ux/ui/user testing (but not core-level development skills) to contribute.
Although I suggested renaming feature plugins to feature experiments, feature projects is pretty good name. It’s nice to see the model evolve and address many of the problems I outlined in 2015. I encourage you to read the full post and let us know what you think of the changes.
It’s better but not optimal.
Without the real world incentive of a commercial budget and an ROI development focus, projects will always be casually managed and waste people’s time.
No one person is responsible for the cost involvement because everyone is paying the bills. This shows up in the casual direction-setting that let “Features-as-Plugins” waste so much of everyone’s time, energy and cost.
Simply to transition [rename] Into “Features-as-Projects” isn’t the solution in and of itself.
A much better approach is to have a more focused way of thinking out loud before direction is set. And the conclusions should be tested before anyone starts writing code of any description, except perhaps for a wireframe or two.
Perhaps a useful proxy for figuring out which projects should get the love ~ and which should get the order of the boot ~ would be to crowdfund them all and see who is willing to put their money on the line for this or that feature/enhancement/fix/whatever?
And by the way, this problem has been around for years and not only in the open source world. Stuff gets developed by clever developers who found it interesting to develop, but when they saw only a handful of people installed it, didn’t want to support it over the long term.
Which is one reason why the repo has so many dead bodies.
Changing the name is good, so long as the focus shifts to thinking and market testing before doing.