The Features as Plugins First Model Is a Mess

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

MP6 WordPress Admin Plugin
MP6 WordPress Admin Plugin

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.

Featured Plugin Development Looks Dead
Feature Plugin Development Looks Dead

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, “Features-as-plugins often become Projects without requirements or tasks, which leads to a non-schedule, and then often require all-or-nothing to go in.” Feature plugins are generally driven by one or two people who might be good developers, but lack project management skills. It’s almost like someone needs to constantly shepherd feature plugins to make sure they’re following a schedule and keeping them all on the same page.

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 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.

There are 13 comments

Comments are closed.