Jen Mylo emphasized usability, as well as encouraged more people to contribute to WordPress. Conversations happened on wp-hackers and trac, but it wasn’t always obvious how new people could get involved with the project. Project growth compounded the problem; it wasn’t easy for a new contributor to understand what was going on, nor how to contribute. Jen wrote about how to get involved, and the development blog announced patch marathons and bug hunts.
Jen brought more structure to the project: she reinstated weekly development chats with agendas and prevented discussions from disappearing down rabbit holes. When she joined the project, core developers communicated in two main ways: via the IRC chat room and by private Skype channel. Skype’s drawback is that it’s closed — it doesn’t create opportunities for other people to get involved. Also, because the main blog at the time, wpdevel.wordpress.com, was on WordPress.com and not WordPress.org, it didn’t feel official. There had been little project management; developers wrote code and pushed it out when it was ready.
At this time, Matt stepped back. Ryan Boren led development, while Jen stepped up to project-manage the software and took a leadership role within the community.
She tried to address communication fragmentation within the project. By 2009, project communication happened in different places: trac, wp-hackers, the #wordpress-dev IRC chat room, wpdevel.wordpress.com, and the WordPress.org development blog. Jen highlights the state of each of WordPress’ primary communication channels: the #wordpress-dev channel had become mostly inactive; wp-hackers had thousands of subscribers, but was often just a troubleshooting forum; the development blog was used for official announcements only; the wpdevel.wordpress.com blog (directed now to https://make.wordpress.org/core) housed team progress updates; Trac had become an unworkable mess with hundreds of irrelevant tickets; and the ideas forum contained many highly voted, but irrelevant threads.
Communication improvements were discussed in a forum thread. Suggestions included: a place other than trac for people to raise things; a way to make it easier for people to write automated unit tests, allowing the community to vote on ideas; greater documentation integration for WordPress and trac; adopting P2 for discussion; and using BuddyPress — a social-networking plugin that is a sister project to WordPress — on WordPress.org.
Amid suggestions were complaints: it was noted that no one official read the ideas forum, timezone differences made IRC meetups difficult to attend, and too many communication channels existed — far too many for people to keep up with. Some people complained about community governance and a lack of transparency. As Jen observed, “Your post just proves the point that communication is an issue. I would not say that WP lacks a clear direction, I would say that it simply hasn’t been communicated properly.”
Jen wanted to clarify how project decisions were made. It wasn’t uncommon for people to toss feature requests into IRC chat. People needed to know what each communication channel was for and understand the correct channels to ask questions and request features.
Much of the development discussion had shifted from wp-hackers to trac. Trac’s main benefit is that it focuses discussion directly on the bug, feature, or enhancement at hand. That said, as more and more people started using it, it became — just like wp-hackers — susceptible to intractable, bikeshed discussions.
Smilies were at the heart of one such recurring discussion. In 2009, a ticket requested replacing WordPress’ smilies with Tango/Gnome smilies. Ryan Boren committed the patch.
The smilies landed first on WordPress.com, which receives daily codebase updates. The feedback was negative and reaction on the trac ticket spiralled; contributors were unhappy that smilies had been changed without discussion. They argued that WordPress had changed users’ content, without giving them any say in it. The discussion spread from trac tickets to community blogs. Some wanted a public poll to aid the decision.
Ryan Boren eventually reverted the change, saying: “Back to the prehistoric smilies that everyone complains about but evidently likes better. 🙂 I was a fool for not appreciating the explosive topic that is smilies, my bad.” [footnote]The smiley debate was reignited in 2014, when WordPress.com updated its emoticons and a proposal was made to produce high-dpi smilies for use on retina displays. Once again, people had strong opinions, as seen across community blogs. As of 2015, the smilies are still not updated.[/footnote]
As well as trying to fix communication problems, some worked on improving documentation. To commit a patch in WordPress core, there is a review process. The WordPress Codex, on the other hand, is the opposite: any contributor can publish documentation immediately. This is a low-friction way to create documentation, but because it lacked rules and structure, it became difficult to navigate; pages fell out of date, and — despite the efforts of the documentation team — it became a mess. User documentation is packaged up with developer documentation, often on the same page, and for many WordPress users and developers, the Codex became less useful. In the meantime, WordPress tutorial blogs proliferated. In the absence of good, official documentation, people went elsewhere.
The Handbook Project sought to create references for theme and plugin development. The team launched a trac instance and wordpress.com blog to manage the handbooks. It can be difficult to recruit long-term help on documentation. With the low-entry barrier, many people make their first WordPress contribution through documentation, but as they figure out the project’s contours they move on to contributing to core. The original handbook project was passed between different people, and by 2014 it was near completion.
In mid-2009, WordPress dropped the long-term security branch — something Mark Jaquith had maintained since 2006. The plan was to maintain it until 2010. During that period, however, there were major changes to WordPress’ security. Backporting those changes into the 2.0.x branch meant complex rewriting that could have introduced new bugs or instability. The developers found that few people were on 2.0; new feature proliferation meant that people upgraded more readily. The legacy branch continued until just six months shy of its 2010 target, and was deprecated in July 2009.
Long-term support branch (LTS) requests remain — specifically from big companies that use WordPress as a CMS — though it’s unlikely that WordPress will ever start a new branch. Matt wrote to wp-hackers:
Not backporting is a conscious decision. I would rather invest 100 hours in backward compatibility in a new version than 2 hours in backporting a fix to an obsolete version of WordPress. Plus, as noted by everyone else, backporting was often impossible because it wasn’t one or two line fixes, it was architecture changes that would touch dozens of files. The LTS was actually less stable with these “fixes” backported because it had almost no one using it.
Rather than supporting an LTS branch, the project focuses on easy updates and compelling features that entice users to upgrade. This iterative process has continued to improve throughout the project’s history, from Matt’s first mention of upgrades in his 2006 State of the Word address, to automatic updates introduced in WordPress 3.7. This approach focuses development on keeping users secure, rather than trying to maintain older software branches.