Component Page Updates for 4.4

Now that 4.4 is underway, let’s update the component pages to reflect 4.4 activity. The Customize, Editor, and Press This pages serve as good templates, though they all need 4.4 updates. The component pages are targeted at beta testers. They should describe the component, list milestones (roadmap), and explain what needs testing and how to test it. Good component pages assist triage. For details, see the previous round of component page updates.

Also, if your component has a corresponding Slack chat, link to the component page from the chat’s channel topic. This assists using Slack in beta testing flows.

Component maintainers, here are your component pages…

Continue reading

#components, #maintainership

John Blackbourn is leading WordPress 4.1 (and announcing new committers!)

I’m pleased to share John Blackbourn (@johnbillion) is the release lead for WordPress 4.1. But please hold your applause until the end, I have a few announcements to get through!

WordPress 4.1 will be kicking off at WordCamp Europe this weekend. As noted yesterday, the first meeting will be at 1400 UTC on Monday, September 29.

You’ve probably seen John in action over the years (his first contribution was more than seven years ago). I’ll also add it’s pretty awesome that @simonwheatley and @s1m0nd of Code for the People (a six-person shop) jumped at the chance to donate a large chunk of John’s time through the end of the year back to the WordPress project. (See also this post for more on the release lead role.)

New committers for WordPress 4.1

As many of you know, the lead developers review and appoint new committers to serve each release cycle, often to work on a particular component or feature. This guest commit access comes up for review after each release and can be renewed. I in particular work closely with every guest committer, providing feedback.

I’m pleased to announce our largest guest committer class ever: Gary Pendergast (@pento), Boone B. Gorges (@boonebgorges), Konstantin Kovshenin (@kovshenin), Aaron Jorbin (@jorbin), and Jeremy Felt (@jeremyfelt).

Konstantin and Gary both enjoy diving into internals and getting their hands dirty with tough bugs and regressions. Jeremy will be continuing to push multisite forward. Jorbin will be focusing on testing and tooling. Boone has been working on a set of great improvements to tax, date, and meta queries, with test coverage to come with it.

These five should be strangers to no one — they’ve all been around the community for years, and not only are they top-notch contributors who embody the project, but they’re generally just really good people.

This will also be John Blackbourn’s third release as a guest committer. I’d also like to welcome back Ian Stewart (@iandstewart), who previously was a committer during the development of Twenty Eleven, and will be back to take the commit reins for the next default theme, Twenty Fifteen.

Scott Taylor (@wonderboymusic) was on fire during 4.0, especially if this terrific post is any testament, continuing a great run. Scott’s WP origin story is pretty great — right as he was getting ready to leave the WordCamp San Francisco 2011 after-party, @koop convinced him to stick around a little longer. We were introduced, and not long after (from the party) his first patch got committed. A thousand contributions later that have made an indelible impact, Scott is now a permanent WordPress committer. We hope to have him around for a long time.

About a year ago Drew Jaynes (@DrewAPicture) was given commit access to lead the hook documentation effort. This was hugely successful. After the effort was complete, Drew’s role evolved into maintaining all inline docs, which has just been wonderful. We appreciate his attention to detail and his dedication to this never-ending effort. Drew is now a permanent committer.

Congratulations to John, Drew, Scott, Gary, Konstantin, Jeremy, Jorbin, Ian, and Boone!

#4-1, #commit, #release-lead

Please propose agenda items for the development meeting…

Please propose agenda items for the development meeting today at 21:00 UTC. Let’s try to keep it to under an hour, like last week’s.

Some to start us off:

  • Consider the Widgets Customizer plugin for 3.9 merge. If you haven’t looked at it yet, please spend some time today before the meeting. Obviously, we all like the idea, but we need to study the implementation and provide feedback. Please comment on that post if you haven’t already.
  • I’d like to propose an initiative for cleaning up a group of 556 tickets during the 3.9 cycle. (It has details, will explain in the meeting.)
  • Quick situation reports for various 3.9 tasks. If you’re working on something, please come armed with a sentence so we can do these rapid-fire — or post it in the comments thread. Some things are moving forward quickly, some aren’t. Where can we help? Here’s a list of what was proposed for 3.9 (see also the comments, which were updated after the last meeting). We need to take the “proposed” label off soon…
  • I’d like to get moving on the Trac component re-organization; I’ll see if there are any questions. We will need some help to move around tickets (ideally adding feedback to them along the way), so I’ll be looking for volunteers and talking about what is needed.

Aren’t familiar with how these meetings work? They’re especially good for breaking logjams — whether that means talking through a major sticking point, finding volunteers to help with something. We also use them to plan out schedules and tasks, make sure everyone is on the same page, and do release post-mortems to see how things went. (As 3.8.1 was released on Thursday, could be good to discuss this and 3.8.2, for example.)

The meeting takes place in IRC on in the #wordpress-dev channel. See you then!

#3-9, #agenda

Proposed Trac component reorganization

Warning, this long. tl;dr: I propose a reorganization of our Trac components. 34 top-level components with two dozen subcomponents. New tree at the bottom. First, an overview of some of our problems.
Continue reading

#components, #trac

JavaScript meeting on Monday @koop @azaozz @carldanley @adamsilverstein…

JavaScript meeting on Monday. @koop @azaozz @carldanley @adamsilverstein @kadamwhite will be meeting on Monday at 9 p.m. EDT (Tuesday, August 20 at 01:00 GMT) in the #wordpress-dev IRC channel. I’ll let them build out an agenda in the comments, but here’s some potential topics I know they’ve been kicking around:

  • JS style, structure, and design patterns, and what new code should look like
  • JS unit testing, including candidate frameworks and where to start
  • APIs, such as WP-style hooks (actions/filters), what form they should take if they should exist
  • Which areas of our JS need refactoring and overhauls, and what that might look like
  • Which JS-heavy features need eventual iteration (often “version 2”)
  • What action items could be done for WP 3.7 and 3.8

#3-7, #javascript

WordPress 3.7 organization

With WordPress 3.7 and 3.8, we’re a project in major transition. Version 3.7 aims to solve for a lot of things that are weighing us down. (See the initial kickoff post.) What do you want to do? In terms of process, here is what is being worked on for 3.7:

Processes, Tools, Workflows

  • New development tools — — run by @koop. If you are interested in Grunt, unit testing (including JS testing), and how we can streamline and modernize our workflows, this is for you.
  • Code reference — inline documentation efforts — run by @rzen, @ericlewis, and @drewapicture. If you are interested in inline documentation, this is for you. See this post to get started.
  • Process changes (including improvements to Trac and how we organize around components). If you want to write some Python for Trac, this is for you. If you’re just interested in helping with component reorganization, stay tuned here — there will be a post soon outlining a new component tree.

Security, Stability, and Updates

We have a few other focuses that all deal with a general theme of security and stability.

  • Passwords. We are aiming to improve the adoption of best security practices by assisting with password generation. #24633@duck_ is also working on some changes to strengthen cookies. #20276. If you are interested in security, this is for you.
  • Updates. @dd32 and @pento will be heading up automatic updates for minor releases, as well as improving the trustworthiness of our upgrader. If you love updates and stability, this is for you.
  • Language packs. We need to separate language files from plugins, themes, and core, allowing them to be maintained and updated independently (and, ideally, automatically). #18200. If you want to help WordPress’ global reach, hook up with me, @dd32, and @markoheijnen.

General Triage

Finally, we have 3,800 (already only 3,600) open tickets on Trac. There are dozens of components with many, many tickets. Already, there have been a few components with a strong base of contributors working on them, including:

  • Multisite, currently being smashed by @jeremyfelt and others. If you like multisite and want to make it better and more stable, this is for you. There are currently 122 open tickets.
  • JavaScript. A number of you have expressed interest on working on JavaScript in core. Whether that is shoring up the stability of existing features, improving existing JS, or working on a JS testing framework, this should be a great working group. @carldanley, @adamsilverstein, @nbachiyski, @kadamwhite, and others expressed interest.
  • Query and Taxonomy. These two advanced areas of core kind of go hand-in-hand, not in the least because @wonderboymusic smashes query tickets with his left hand and taxonomy tickets with his right. If you’re interested in bringing down these tickets (68 and 93 open), this is for you.
  • General triage. Folks like @c3mdigital and @avryl have been already going through old tickets either closing them out or finding diamonds in the rough. Or maybe you find that one of the many open components catches your interest. (Go here and choose any component from the drop-down to see all open tickets.) We’ll be coordinating efforts to work together both in IRC (especially during the weekly meetings) and here on make/core.
  • Components with a lot of open tickets: General (376 tickets), Administration (302 tickets), Media (221 tickets), Template (161 tickets), Comments (135 tickets), Users (107 tickets), Themes (105 tickets), Formatting (98 tickets), Menus (96 tickets), Widgets (90 tickets), Plugins (90 tickets), Editor (85 tickets), Upgrade/Install (84 tickets), Import (70 tickets). If you want to do general triage, General and Administration in particular need a lot of work!

Today during the weekly meeting, we’ll be talking about ongoing efforts, rallying the troops and helping to assemble working groups, and setting up some times for regular triage meetings.

So, what do you want to work on? Let’s start coordinating in the comments.


A New Frontier for Core Development

In a little over a decade, we’ve made twenty five thousand commits to WordPress. WordPress (along with the web itself) has come a long way, but our development workflow has remained largely the same.

As a part 3.7, I’ll be leading an effort to revamp and streamline our development workflow. We’re going to bring all of our core components—our code, our tests, and our tooling—under one roof. Developers will be able to use and improve the tools we’re already working with day-to-day, and we’ll be able to add new tools to make working with WordPress even easier.

We’re also making sure that any changes are compatible with our current workflow, so you won’t have to change the way you work. These changes won’t break any existing checkouts or scripts that use Now that we’ve cleared that up…

This week, we’re creating a new repository:

The develop repository will be the new home for all core development. We’re going to sync over all of the commits from and will reorganize this new repository to use a new directory structure:

The src directory

This is the WordPress core source. All of the existing WordPress core files will be moved into this directory. You’ll develop and test against this directory as usual, but the real power will come from using the rest of the tools in the repository. The contents will be optimized for development, not production (this means uncompressed files—including our internal libraries).

The tests directory

We’re going to pull our internal unit tests into this repository as well. This will make testing a cinch, and allow us to commit patches that include changes to both the source and the unit tests. We’ll also add JavaScript unit tests during the 3.7 cycle.

The tools directory

Our tools directory will include all of the little things that make our lives as developers easier. To start, we’ll include our internationalization tools, which will allow us to generate pot files from within core. We’ll also include a handful of scripts that some of us use to interact with Trac, like scripts to upload and apply patches.

The root directory

This frees up the root directory to include configuration files, allowing WordPress to interact more seamlessly with other applications and services like Travis CI and Composer.

A build process

We’ve had an implicit build process in the WordPress codebase for a considerable time now. Most of that process is now contained within bumpbot, a little script that lives on the servers. Whenever we update CSS or JavaScript files, bumpbot comes around, minifies them, and commits the result. Despite bumpbot’s efforts, this process is less than ideal. Our source files (in this case, JavaScript and CSS) live alongside our production-optimized files, which causes confusion and makes contributing to core considerably more difficult. Our built output—the files optimized for machines—shouldn’t live alongside the source code that’s optimized for developers, and beyond that, shouldn’t be tracked in source control.

We’re adopting Grunt to write a real build process and help us manage and run our various tools. Grunt is a JavaScript task runner that has a robust ecosystem of plugins focused around building modern web applications. We can include tools such as integrated testing, minification, linting (for PHP, JS, and CSS), image optimization, and LiveReload—and that’s just the beginning.

Using Grunt will be an optional but encouraged part of WordPress development. These tools are all built atop Node.js, which Grunt needs in order to function.

So what’s happening to

In a word, nothing. The contents of the core repository have always been optimized for production, and that’s not going to change. will now serve as the repository for our built output: every time we make a commit that changes the build, the core build will be updated with a corresponding commit. As mentioned earlier, scripts and checkouts will continue to function as expected. When you download a zip of WordPress, it will still be generated from this repository.

Let’s get started

The develop repository will go live soon. For now, I’ve made a preparatory repository available to illustrate the structure I’ve described above, and allow us to experiment with this new workflow. You can learn more about how the tools are installed and used on the repository page. Please provide feedback on this post—the goal is not to build all of the code there first, but to provide insight into the new process.

Lastly, I’d like to say thank you to all of the contributors who helped shape this idea over the past few months, especially at WordCamp San Francisco’s hack day. Together, we’ve created a structure that elegantly addresses many of our existing problems and opens the door to countless possibilities for better development practices.