Dev Chat for Thursday, September 30 is officially cancelled, due to unexpected conflicts and family emergencies among the lead team.

Please feel free to congregate as usual, and take over the asylum to discuss patches in progress, best approaches to fixing bugs, and whatever else a collaborative hour can help move forward. Remember, feature freeze is in 2 weeks, so if you have a pet ticket you’re hoping to get in, try to get the patch up this week.

Will return next week at the regular time. In meantime, anyone who has been assigned a task for 3.1 should post a comment here with an update on status.

Suggest Agenda Items for today’s meet-up
Please keep them on-topic

wp-db.php is now always included. Database drop-ins should continue to work without any adjustment in most cases (or can be adjusted to work with small tweaks).

This is for performance as we are no longer conditionally including a file. It also allows db.php files to cleanly extend wpdb, which previously required a bit of tinkering.

See http://core.trac.wordpress.org/ticket/14508.

CPT enhancements

I’m trying to put together a small but well-defined set of enhancements that custom post types deserve consideration in 3.1.

What I have so far is this:

• Opt-in archive/index pages for custom post types
• Opt-in default meta capability handling for custom post types
• Improve the custom post status API, and make them type-specific

Beyond that, I’m also thinking about opt-in ways to get more than the default post types displayed on other views. As it is now, we currently also allow searching for pages for example, so we would more or less be extending that. You may want to allow a post type to show up on the category or tag pages, for example. The API ideally wouldn’t be more complicated than, say, register_taxonomy_for_object_type.

What are your thoughts? Let me know your pet bugs, peeves, and workarounds. (Just keep in mind we’re aiming for small, defined scope here. KISS.)

As you know, GSoC is over. I’ll be writing up a summary of all the student projects once we finish reviewing them all, but general stat is that out of our 15 students, all but 2 passed both their midterm and final evaluation (87% success rate). We’ll be sending two representatives to the GSoC mentor summit in October in California: Aaron Campbell and Boone Gorges, with John James Jacoby as the alternate.

The Purpose of the Dev Chat

Every now and then it seems like people forget the purpose of the dev chat, or new community members aren’t clear on it, so I thought this, the beginning of a new development cycle, would be a good time to reiterate the purpose of the dev chat. The dev chat is a weekly product team meeting (see About the Dev Chat), not a weekly social gathering/town hall/q&a. For anyone who’s ever worked at a software company, an agency, etc., this should be a familiar concept: The team working on a software project meets, everyone gives an update on their part of the project, any roadblocks/red flags are identified and solutions are discussed, and updated assignments are given/confirmed.

Each release cycle we remind people that this is the intended use of the dev chat, but somehow along the way we wind up losing track of that, and it turns into a combination of dev chat + ideas forum + wp-hackers live. Because the 3.1 cycle is so short (feature freeze is little more than a month away!), we need to stay focused this time around. We will be much stricter about staying on agenda, and while anyone is welcome to attend, we will ask people who have questions/suggestions that are not on the agenda to either wait until the dev chat is over or to bring it up in another venue, such as wp-hackers, on a Trac ticket, or in the forums.

It’s understandable that many people want a direct line to the lead developers, and knowing they will be in a specific place at a specific time makes it easy to corner them to pitch pet requests, but please respect that these busy individuals are continually prioritizing the pet requests of hundreds of people and millions of users. Hijacking their product team meeting doesn’t help anyone’s cause.

“Are you kicking me out?” some people may be thinking to themselves. No. The #wordpress-dev channel is open 24/7, and given the time zone distribution, there’s usually one or more lead developers in there, as well as numerous contributors. Discussion about core topics is welcome in the #wordpress-dev channel any time, and questions are usually answered gladly (and let’s face it, @nacin never sleeps). The weekly team meeting just needs to stay on target, on schedule, and focused on the actual contributing team. Though most people are volunteers working on WordPress core part-time, contributors are part of a product team, and their time should be treated with the same respect that any corporate product team would receive, if not more.

If you are not working on patches for this cycle, please let the core product team get through its agenda. Hang on to your other questions to ask during one of the 167 hours per week in the channel that don’t have a specific agenda/schedule, or ask in another venue (Trac tickets are best, since it’s asynchronous and acts as the permanent discussion record for each feature). A good guideline here would be to think of another piece of software that you use. Let’s say Firefox or Microsoft Word. If you wanted a new feature, or wished they would code something a certain way so you could do something you specifically want to do for your clients, would you interrupt their product team meetings to ask for it? If not, then please grant the same courtesy to the WordPress developers. If you would interrupt them because you found something so major that it really needed to be addressed asap (like a security problem), then please don’t wait for the weekly dev chat! Get in touch with the developers in the channel right away, so that someone can assess the issue.

If you’re following along in the dev chat and while the team is discussing a specific feature you think of something about the way they’re approaching it that you feel certain the lead devs/core contributors haven’t thought of yet, you are welcome to speak up (having read the Trac ticket first is a good idea, to make sure you’re not raising something that has already been discussed and dismissed). Maybe your idea is brilliant and everyone will thank you for the suggestion/fresh approach — go you! However, if you make your suggestion and the product team is not inclined to take it, please respect their decision. At that point, the best way to try and convince someone that your suggestion is a better approach is to code the patch yourself and upload it to Trac. Patches speak much louder than words in this case.

Remember, the WordPress motto is “Code is poetry,” and for this particular hour each week, the poets are the main event. Thanks!

Ryan is traveling today and we forgot to reschedule the dev chat, so today will be a short and sweet confirmation of who’s working on what for 3.1. No new business.

Agenda:

• Summary of the big tasks that have been approved/assigned: Jane, Mark Jaquith, Peter Westwood, Nacin
• Assign any unclaimed approved-but-developerless tasks
• Brief review of 3.1 scope, and why some suggestions made on wpdevel are out of scope for this release Jane, Nacin, Jaquith, Westi
• Trac/bug review – Westi, Nacin, Jaquith

The WordPress.org support forums now have subscribe by email, to tags.

To use, login, then view any single tag page. At the bottom of the page, sorta hidden on the left side, you’ll see a link called “Subscribe to Tag via Email”. It’s a toggle.

Note: If you subscribe to heavily trafficked tags, you’re likely to get a LOT of emails. I suggest you use this sparingly, or get an email system that can cope.

Note the second: I fully expect there to be bugs. This is new. Expect fixes when I find them.

My suggestion on “content types” has gotten completely out of hand, with post styles, post templates…

To clarify, my idea for the completion of that “feature” would be a wiki page with a taxonomy name and a few slugs we all agreed on (aside, gallery, quote, video…) and reaching out to the folks doing tumblelog themes to ask them to support it, noticeably Woo but also 2010, P2, Typographic.

Basically a convention different themes can use so if you switch from one to another you don’t have to redo all your archives.

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.