Released in late 2013, WordPress 3.8 was packed with new features including, a new theme browser experience, widgets area chooser, and a redesign of the backend. It’s also the first release to include a feature using a new formal development process called features-as-plugins first. The backend redesign started off as a plugin called MP6 with development beginning in March, 2013.
Prior to MP6, features were largely developed inside of core during the development cycle. This method caused some versions to be delayed, as was the case for WordPress 3.6. The success of MP6 proved that by developing core features as plugins first, they were easier to test, manage, and merge into core at the appropriate time. Since adopting the development process, at least seven features have landed in core. However, as an outsider looking in, the process seems to be falling apart.
MP6 Set The Bar
Each week, Matt Mullenweg and Matt Thomas released a new version for people to test. They also kept everyone updated on what changed and left the comment form open to solicit feedback. This made it easy for people to participate in the development and testing process. By using P2 and the comment section, it was a lot easier to provide feedback. Since MP6 was a plugin, testing it was as easy as installing it on a stable version of WordPress.
The Lack of a Testing Audience
MP6 was available for download on the WordPress plugin directory. This made it accessible to anyone who wanted to test it. Recent plugins like the User Session Manager by John Blackbourn don’t have any P2 posts on the Make WordPress Core site. As with several other features, discussion took place within a trac ticket. Development of the plugin was handled on Github until it received a pass to be merged into core. Having a feature plugin only available on Github and a lack of communication surrounding the feature prevents a lot of people from potentially being part of the testing group.
WordPress lead developer, Ryan Boren, noted in an open thread in November of 2014, that when it comes to gathering a testing audience, no feature plugin has reached the standards set by MP6. For plugins to be merged into core, Boren suggested the following items should be met:
- 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.
Several feature plugins fail to adhere to many of these proposed guidelines. In June of 2014, Andrew Nacin added a “Beta Testing” tab to the add plugins screen for those who use WordPress trunk. The tab lists Feature Plugins that are available for testing.
Based on the results in the screenshot, it looks like every feature plugin is dead in the water, including the WP API. However, if you look at the activity for WP API on Github, there’s plenty of development taking place. How can more people participate in the testing process if feature plugins are not routinely updated and available for download in the directory? This needs to change sooner rather than later.
Feature Plugins are More Like Experiments
Feature plugins are not guaranteed to be added to WordPress. Instead, the process is similar to a lab with each one being an experiment. Sometimes a plugin won’t be added but parts of it will. For example, many of the improvements to the post editor in 3.9, 4.0, and 4.1 are derived from the Front-end Editor. Maybe the core team should think about renaming them to feature experiments as it’s more representative of what they really are.
Project Management
When I brought up the subject of feature plugin development at the January 7th core development meeting, Scott Taylor made an excellent point, “F
The Process Needs to be Fixed
It’s clear that the feature plugin development process is disjointed at best. Communication is lacking, synchronized development between plugins on Github and WordPress.org is non-existent, and some plugins are merged too quickly. If users are to receive the maximum benefits from the experimental process, it needs to be orchestrated better. At least the core team is aware of the problems and is working towards improving the situation for the 4.2 development cycle.
In my opinion, the problem with the current Feature-Plugin model is that it lacks the *context* of a core team-defined road map. I have long complained about the lack of a robust, publicly available, long-term road map for WordPress development.
So, without that context, the Feature-Plugin model is akin to throwing strands of undercooked spaghetti against the wall, and seeing what sticks. There’s no direction, and no buy-in, either from core or from the contributor community. Thus, you end up with a bunch of Feature Plugins that wither on the vine. Too many development resources get diluted among too many Feature Plugins, with no real project-management type leadership.
I would (still) love to see WordPress development have some defined development goals and milestones. Then, direct contributor resources toward those Feature Plugins that best accomplish those goals.