Process and Scope for 3.1, Part I

Last night’s dev chat was the first of two planning meetings for 3.1. The intention of this meeting was to remind everyone of the goals for 3.1, identify features that the lead team has prioritized, get an early sense of who’s willing to work on what, and to talk about the timeline. Much of what is written here is what was posted in the dev chat last night, to retain consistency.

There were a lot of suggestions on the table. That said, quite a few suggestions fall outside the stated intentions of 3.1 (quick, fast dev cycle, no big huge projects). For anyone late to the party, here are the goals of 3.1: to have a very short dev cycle, a decent amount of testing time, and a release in mid-December. Low on new features, heavy on ui and code cleanup, and avoidance of schema changes. Save the big ideas for 3.2 where we’ll have the liberty to implement those ideas in PHP5. No schema changes and no big new APIs.

This means stuff that got worked on over the summer or can be taken more or less wholesale from a plugin or patch has a better chance of being allowed into 3.1 than a brand new idea that doesn’t already have code written. In cases where we can do something small in 3.1 to pave the way for something bigger in 3.2, that will be the approach.

To that end, the leads have identified some of the suggestions, both from the wpdevel and from other sources such as the ideas forum/WordCamp feedback/support forums, that would be appealing to include in 3.1. We’ve also identified some things that definitely do NOT fit into the scope of 3.1.

An example of something that doesn’t fit:
Media overhauls. We’re going to target 3.2 for a bunch of media fixes. The underlying code is too complex to do anything hardcore this fast. The only media things that would be acceptable in 3.1 would be small updates that don’t change the overall flow, such as the request to make the caption able to hold html to include links. If someone volunteered to code that, that addition would be acceptable in terms of scope. Other discrete things like this would work. Refactoring the way featured images work would be out of scope.

Another thing that doesn’t fit is per-post/page/category widget selection. There are plugins that do this, and the code is nuts underneath. We want to stick to easy wins for 3.1.

Now on to things that fit!

Features

Polishing features introduced in 3.0 can be one umbrella task. BUT — this means spit and polish ONLY, not adding features to features.

New feature: Mark Jaquith is committed to getting in some advanced taxonomy queries stuff, which already has some movement in trac via scribu.

Mark Jaquith also wanted to get down and dirty with roles/caps, but that’s just too big an undertaking for 3.1. Maybe in 3.1 we could do the get_users() and friends cleanup that scribu started on to pave the way for role cap cleanup next time around.

In short? Mark Jaquith and scribu will be joined at the hip this cycle. :)

New feature: Internal linking. This is my pet user feature for this release. It has been requested from users for years, got the most +1s on the wpdevel post last week, and is a missing piece of true CMS functionality. Since we likely won’t have Andrew Ozz for this release, Daryl Koopersmith is going to take a stab at this, with backup from Austin Matzko if needed.

New feature: The ajaxified admin screens that scribu did for GSoC, with some UI cleanup applied. There was also a GSoC project by Matt H on comment moderation that needs to be reviewed for inclusion.

New feature: Admin Bar. Connect the back end to the front end. Most useful for people on multisite installs, but still useful for single-site users in providing 1-click access to dashboard, new post form, etc. We’ll be looking at both the original Viper007Bond admin bar plugin and the wordpress.com revised admin bar recently done by Andy Peatling. Note: there was some resistance to this being in core rather than a plugin. A compromise of making it optional was discussed.

Cleanup: UX/UI cleanup across the application, including multisite. This could turn into a ton of new dev, so we need to restrain ourselves. The UI group will do a review and come up with a list. Jane Wells and John O’Nolan will manage UI contributions from the group so that approved UI makes it into tickets.

Ongoing maintenance: Bug fixes. Peter Westwood is all over bug fixes. Anyone and everyone invited to submit patches for known bugs.

New feature: Separate network dashboard from the site dashboards (in multisite). Ryan started on this over the summer, and all agreed it would be great. Needs some UI love. Ryan also looked at doing a personal dashboard to replace the wonky global dashboard you get in multisite when someone has an account but no site. This might be a better 3.2 candidate, but we’ll see if we can get it to a reasonable place in time for 3.1.

There are some small fixes to the custom post types API that ought to be made, while staying within the ‘no big API things’ guideline. Nacin is taking charge of this.

I’d like to swipe the wordpress.com UI for searching/browsing installed themes, as it’s better than what we have in core (especially useful for multisite and sites with lots of installed themes, like those on shared hosting). I helped on the UI when John Godley made it last year, so I’d be comfortable with almost a straight swipe.

New feature: Post templates/post styles. Ryan will be handling this one.

New feature: Making QuickPress a template tag, so it can be used for front-end posting. Aaron Jorbin will be handling this.

Other suggestions not on this list that fit into the 3.1 guidelines (no schema changes, no big new APIs, etc) will be considered until feature freeze if a well-tested patch has been posted by then. Well-tested means more than one person, so if you want your pet project to be considered for 3.1, publicize your patch and get people to test it and post their results to the trac ticket! If you do not take on this responsibility, please do not complain if your patch is not considered; tested patches will always get priority.

Schedule

We want to release mid-December, preferably no later than December 15, so that the holidays won’t interfere with the release. To that end, here is the current plan:

September 9 – Confirm planned scope.

October 15 – Feature freeze; no new features added after this point, so that testing can begin on a stable-ish product (including usabilty testing of new features).

November 1 – Primary code freeze; any last adjustments based on testing after feature freeze should be finished by now and the focus shifts to fixing bugs to get to a stable beta.

November 15 – Beta period beings; from this point on, no more enhancements, only bug fixes.

December 1 – String freeze; translators rejoice.

December 15 – Release WordPress 3.1

So that’s the current thinking. The leads will be reviewing existing tickets and patches this week and working out the feasibility of including all the items outlined above. Next dev chat should see a conclusion to 3.1 scope planning, with some firm decisions on in/out and dates.