The 3.6 release cycle was challenging; it precipitated a new approach to the development process. Two core WordPress philosophies, design for the majority and again, deadlines are not arbitrary, were tested. The 3.6 release cycle process followed the cycle started in WordPress 3.4: there was a unified theme for the release — this time content editing. Small teams worked on key features. Some features need more research and development than can be achieved within a single development cycle, and the WordPress 3.6 cycle surfaced this flaw.
Post formats were 3.6’s headline feature. Introduced in WordPress 3.1., post formats allow theme developers to lend a unique visual treatment to specific post types.
Post formats lacked a standard user interface. In WordPress 3.6, release leads Mark Jaquith and Aaron Campbell tackled the problem. The release cycle had different stages: in the scoping chat, the release lead decided on the release’s key features, created teams, and assigned feature leads. Feature leads ran their teams. The release leads coordinated with the teams and made the final decision on what made the release.
Carrying out major user interface changes in just a few months is challenging, at best. WordPress 3.5 demonstrated that to meet the deadline, the release leads needed to put in heroic coding efforts.
The 3.6 release encountered problems; features were dropped as contributors discovered they’d overcommitted themselves. The biggest issue was around the post formats user interface, inspired by Alex King’s Post Format Admin UI. Much thought and study went into the post formats UI. Which UI would offer users a logical, intuitive workflow, without adding needless complexity to the UI or the experience?
The problem was that despite time spent on wireframes and development, the team ended up unimpressed. They created specifications, built to the specifications, and were unhappy with the result. “It’s like ordering something from the restaurant that sounds great,” says Aaron Campbell, “but as soon as it sits in front of you and you smell it, it’s like, ‘Ahh, definitely not what I was in the mood for.'” Even during WordPress 3.6’s beta period, community members experimented with better approaches to the problem.
April 29 was WordPress 3.6’s target release date. On April 23, Jen — who had by that point stepped back from her involvement in development — said that post formats weren’t ready. She said that the user interface was confusing, underscoring WordPress’ deadlines are not arbitrary philosophy. The thread, in addition to highlighting the post formats UI flaws, showed that not everyone supported deadlines are not arbitrary. Ryan Boren wrote:
The four month deadline is so fanciful as to be arbitrary. It always has been. Historically, we just can’t do a major release with a marquee UI feature in that time, certainly not without heroic efforts of the 3.5 sort. So we end up facing decisions like this. Every single release we wonder if we have to punt the marquee feature. Punting often requires major surgery that can be as much work as finishing the feature. Punting is demoralizing. Four month releases are empty promises that bring us here.
In the end, Mark and Aaron pulled post formats. A lot of work had to go in to removing it from core; the release was heavily delayed, finally appearing on August 1, 2013 — three months after the intended release date. The team promised to turn the post formats feature into a plugin, but the plugin never materialized.
Again, a user-facing feature held up a WordPress release. Because features were tied to the development cycle, it meant that the release cycle’s duration restricted and compromised UI features and/or major architectural changes. Just like tagging before it, post formats was a problem too complex to solve in a few short months. It isn’t always easy to make interface decisions. It’s harder to iterate on design than on code.
When the release deadline approaches and a feature isn’t ready, the development team rushes to try to get it finished. The release is delayed by a week, and then by another week, and in some extreme cases, as was the case with WordPress 3.6, the release is delayed by months. By that point, it becomes impossible to give a firm date for when a release will happen. And the process becomes more complicated as the release lead oscillates between trying to improve a feature and deciding to pull it. Up until 3.6, there was no contingency plan built into the development process that allowed for these challenges in designing a user-facing UI.
The solution to this problem was available, and always had been available, within WordPress’ infrastructure. Twice before, core user features had been pulled from plugins into core — widgets and menus. Widgets had been built for the WordPress.com audience, turned into a plugin, and brought in to core. Menus had stumped the core development team and they solved that problem with a plugin. In both these cases, feature design and testing happened long before approaching core. And as the WordPress 3.6 cycle dragged on, a small group of designers worked on a new WordPress feature in a plugin: it was a project called MP6. The project would be the flagship for a new approach to development that had a lasting influence on how WordPress features were developed.