Dev Blog: Early 2010 WordCamps

Rested up from the holidays? I hope so, because the new year has begun and a lot is going to be happening with WordPress in 2010, and you definitely want to be a part of it. Later this week the scope for version 3.0 (featuring the addition of MU functionality to the WordPress codebase) will be decided in the IRC developer chat*, based on feedback provided by users like you. But it’s no fun to live by IRC alone, which is why we love WordCamps. Attending a WordCamp gives you a chance to meet people in your local community who are working with WordPress, as well as core contributors, theme designers, plugin developers, Codex writers, support forum moderators and other WordPress volunteers who’ve made WordPress what it is today. Add this New Year’s Resolution to your 2010 list if it’s not on there already: Attend a WordCamp, meet at least 5 new local people, learn something new, and if you have the chance, buy a drink for someone who’s volunteered their time and expertise to the WordPress open source project. To help you keep your resolution, here is a list of the upcoming WordCamps for the next three months, followed by what I know so far about each one.

January 8–9: WordCamp Atlanta
January 23: WordCamp Boston
January 30: WordCamp Greece in Thessaloniki
January 30: WordCamp Indonesia in Jakarta
February 27: WordCamp Fukuoka
March 6–7: WordCamp Ireland in Kilkenny
March 27–28: WordCamp Toronto

NORTH AMERICA

January 8–9: WordCamp Atlanta. First WordCamp of the year, and it’s already sold out — twice! They changed to a bigger venue based on demand, from Georgia Tech to the Atlanta campus of Savannah College of Art and Design (SCAD). They’re still letting people onto the waitlist, if you’re interested. A guaranteed way to get in would be to sponsor the event, and they’re taking last-minute sponsors right now. Atlanta will have sessions on Friday evening and all day Saturday. I’ll be opening the Saturday program with WordPress Resolutions: What to Expect in 2010. After a day of design, development and content track sessions, Lead Developer Mark Jaquith will take the closing slot for a Town Hall-style Q&A. The attendee list (follow link, scroll down) includes a number of WordPress core contributors, theme/plugin developers, and support providers as well as proof that Atlanta has a strong WordPress user base.

January 23: WordCamp Boston. I think WordCamp Boston is trying to one-up every WordCamp the organizers have been to, including the awesome NYC from November, and it looks like they might succeed. From Doc Searls and David Weinberger as keynote speakers to the multiple-track, unconference and Ignite sessions to the sweet-looking venue and the party plans, this one has got it going on. I credit it in part to the fact that they are one of the few WordCamps to follow the advice of having an organizing team of more than just 2 or 3 people, so the work is better distributed. I see a number of familiar names on the attendee list, but even more that I don’t know, so I’m looking forward to meeting the Boston WordPress community. They’re still selling tickets, so if you’re in the northeast, you should try to make it. I’ll be at this one also, talking about how the merge with MU will affect the WordPress admin (by then we should have started figuring it out!).

March 27–28: WordCamp Toronto. The last two Toronto WordCamps have been really good. I heard there would be one in March, but their site right now is just taking emails for notification. I’ve contacted the organizer to see what’s up, and he says the site will likely go live this week. They’re looking for volunteers to help organize this year’s event, so if you’re interested, it would be a great opportunity to get involved. Believe me, volunteering at a WordCamp is one of the best ways to make sure you meet a lot of other attendees.

ASIA

January 30: WordCamp Indonesia. WordCamp Indonesia will be in Jakarta again this year. I love how they worded the beginning of their sessions page. “Come in, we’ll get you breakfast and coffee, you’ll register, there’ll be networking. It’ll be great.” There will be a single track of sessions, but there are several time slots set aside for ad-hoc discussion and breakout sessions.

February 27: WordCamp Fukuoka. WordCamp Fukuoka is just getting its site up, too, so check back periodically a little later for more information. One of their visiting speakers will be Noel Jackson, developer of the Press This bookmarklet as well as themes like P2 and Monotone/Duotone.

EUROPE

January 30: WordCamp Greece. WordCamp Greece will be held in Thessaloniki, and they expect about 100-150 people to attend.The program includes regular sessions on the usual topics (how-to, programming, SEO, multi-language sites, etc) as well as “QuickRounds,” which will showcase Greek projects based on WordPress. I’m especially intrigued by the “WordPress vs. Expression Engine” session. Whenever people compare different publishing platforms, it’s interesting to see which features they highlight. I hope someone gets video from this one and posts it to the WordCamp section of WordPress.tv.

March 6–7: WordCamp Ireland. WordCamp Ireland will be in Kilkenny, and for such a geographically small country, it’s got an impressive list of speakers, including Donncha O Caoimh, lead developer of WordPress MU. The program includes three tracks: Intro, Blogger, and Developer, and I think this will be the first WordCamp I’ve heard of that is deliberately family-friendly, with on-site child care. They’re also going to have a charging station for mobile devices, which is clever. It’s not confirmed yet, but I think I’ll be at this one, too.

If you want to attend a WordCamp but don’t know of one near you, check out WordCamp.org for the official list (updated frequently). That’s also where you would start if you wanted to organize a WordCamp in your area.

*Developer chats are held Thursdays at 21:00 UTC in the #wordpress-dev channel at irc.freenode.com.

Dev Blog: Setting Scope

Merry Christmas! One of the things that was discussed at the core commit team meetup was release scope (and scope creep). Now that 2.9 is out and it’s time to start thinking about 3.0, we think it would be appropriate to stop and take a breath before diving in, and make a plan in advance. What winds up happening is that during each release cycle a few new features are selected for inclusion, but then right up until feature freeze (and/or beta cycle), people keep adding feature requests, patches for enhancements, and ongoing bug reports. This means each release winds up getting pushed out later than planned, and with so many things going in per release, it becomes harder to catch new bugs.

The as-long-as-we’re-not-in-freeze-yet model isn’t working. People wind up waiting months longer for new features they want, like Trash and Image Editing, because we’re still adding other things and then we need to test them all. If we kept the releases smaller feature-wise, we could push out the new stuff sooner (3 releases per year is the goal) and have more focused beta testing, making the releases themselves better. It’s hard, because everyone has their pet features and fixes, and if there’s a patch, why not get it in this release rather than waiting? Sometimes people complain that a patch has been waiting to be committed for weeks or months, but what no one ever seems to bring up is that sometimes patches introduce new bugs, and the more we add at once, the harder it is to keep it all well-tested on various platforms, in different hosting environments, etc. So. What’s our proposal?

We take a page from the world of project management and we make a project plan before we jump into the dev cycle. We let everyone propose features and enhancements, and we choose a limited number to include in 3.0 (in this case we need to be especially stringent, because the merge of WordPress and WordPress MU will automatically mean a lot of work) and set a realistic release date that we stick to. We create a tentative set of features for the next two releases, to be re-evaluated at the beginning of the next cycle, so that people know the community is committed to certain features, as opposed to the vague “future release” label we now use for everything not included in the current version. We fix bugs that are reproducible and affect a large number of users before focusing on edge case bugs or bugs that haven’t been well-described or reproduced. We stop diverting our attention from agreed-upon goals when a “squeaky wheel” decides we should all be focused on something else. There are always things that pop up unexpectedly, but we need to do a better job of restraining ourselves when it comes to trying to sneak things into the current release (I include myself in this, of course…as a UX person I always wish we could do everything all at once!).

As an open source project, we accomplish more when we work together than we do following individual agendas, and we need to keep our project focused on commonly-agreed-upon goals instead of following tangents whenever a community member starts to take us on one, regardless of whether it’s to follow a cool idea that everyone loves or a suggestion based on a personal agenda, and regardless of whether it’s a newbie who doesn’t know any better or a frequent contributor or committer who has a strong opinion and a loud voice (so to speak). The issue here is that it’s easy to get distracted, so we need to create a structure that will help us keep moving forward instead of getting sidetracked. We need to keep Trac clean for the current dev cycle so that it includes confirmed features and bug reports, and all new feature suggestions go into a different milestone.

We think it’s at least worth a try. When we re-start the weekly IRC dev chats in 2010, the first meeting will be to talk about the scope of 3.0. When we’ve got a general agreement about what will be included, we’ll create the appropriate Trac tickets, and punt tickets for non-3.0 feature requests/enhancements to a future release so we can stay focused. New bug reports will still come in to the current milestone. It’s going to be hard. There are at least a dozen new features that I feel like we’ve pushed back multiple times that I’d like to see in core, but for this experiment, I’m just going to keep reminding myself, “You can do that with a plugin!”

Sound off on the features you would like to see in version 3.0.

2010: A Theme Odyssey

After the video from the core team meetup was posted, the topic that seemed to get the most attention on Twitter and various community sites was Matt’s announcement that there would be a new default theme in 2010, so I thought I’d start with that as the first of the meetup summaries.

When Kubrick was bundled with core back in 2005, it was a cutting edge theme. Custom header, rounded corners, clean design… if you were using WordPress back then, let’s face it, you were impressed. Time moves on, though, fashions change, new styles become old standards, and what was once cutting edge suddenly seems old-fashioned and out of date.

So, a new bundled theme in 2010? We think it’s a good idea. Something nice and light that can serve as a good example theme, include newer theme-based features, and look nice (and current) on a public site. We’d like to introduce a new default theme with version 3.0, which is anticipated to come out in mid-2010 (hence the name), and think it would be good for it to blend well aesthetically with WordPress itself.

I’d been advocating moving toward Elastic, the theme framework/WYSIWYG theme editor that was one of our Google Summer of Code student projects, but after some discussion I agreed with the guys that while Elastic is awesome and should be promoted as a community development project, it’s heavier than a default theme needs to be. The default theme doesn’t need to be a full-featured framework, it just needs to work well, look awesome, have good code and be a good starting point for beginning themers. We were thinking of a fairly minimalist design that would make it easy to customize.

As for the code, there’s a question of if it will really be a new theme, or if it will be a re-styled and updated version of Kubrick.  We don’t know the final answer to that yet, because the ultimate decision will be made with the community’s input, but we believe all new markup is the way to go. What do you think? Without venturing into theme framework territory, are there features you think a new default theme should have? Some people have been talking about it on Trac over the past year, if you wonder what’s been tossed around so far. I thought about posting a poll here (you know how I love posting polls to gauge opinion), but in this case I think a discussion thread might be better, so that each vote can explain the reason behind it. So, have an opinion on what a new default theme should include? Weigh in at the forums.

Core Team Meetup Results

To get started, here’s a short video from the meetup discussing some of the topics and 2.9. In the opening pan, you’ll see (L-R) Andrew Ozz, Mark Jaquith, Jane Wells, Peter Westwood, and Ryan Boren, followed by Matt Mullenweg as the first person talking. Tip: go full-screen in HD to feel like you were there.

Last week, I posted about the fact that Trac would be quiet for a few days while the core commit team met in person for the first time to talk about some goals for WordPress in the coming year. That prediction wound up being a little inaccurate, as having everyone together inspired a Trac sprint to get us closer to shipping 2.9. As of this morning there are only 11 tickets left against the 2.9 milestone. Yay! I’m sensing a Release Candidate in the near future.

I’d planned to write a summary post to encapsulate the discussions we had over our 3 day meetup, but to be honest, all-day (and night) every-day meetings creates a ton of things to summarize, and the post would be a novella. So instead of one long post, I’m going to split it up into a series and post a summary of the discussion on one or two topics per day until I’ve posted them all. Think of it like a WordPress advent calendar. For today’s post, enjoy the video above and I’ll list the topics we covered to give you an idea of what will be included in the upcoming summary posts.

Topics: Direction for the coming year(s), canonical plugins, social i18n for plugins, plugin salvage (like UDRP for abandoned plugins), WordPress/MU merge, default themes, CMS functionality (custom taxonomies, types, statuses, queries), cross-content taxonomy, media functions and UI, community “levels” based on activity, defining scope of releases, site menu management, communications within the community, lessons learned from past releases, mentorship programs, Trac issues, wordpress.org redesign, documentation, community code of conduct.

You can see why I didn’t want to try to cram it all into one post, right?

Just to make sure it’s clear in everyone’s minds, I want to reiterate that these discussions were just that: discussions. They were not secret meetings ending in hard and fast decisions. The idea was to 1) get the core commit team on the same page in order to improve workflow efficiency and communication, and 2) come out of the meetup with a long list of things we know we want to work on in the coming year, and from there to work with the broader community to determine priorities/strategies before starting the work of getting it all done. As I finish off 2009 by posting summaries of the meetup conversations, I hope you’ll all plan to start 2010 with enthusiastic participation in one or more of the projects that will take these conservations from concept to reality.

Canonical Plugins (Say What?)

There have been a lot of references to “canonical plugins” over the past year, especially at WordCamps by Matt, but we haven’t really posted anything official about the idea, nor have we really made much progress beyond discussions about how awesome it would be to have canonical plugins and how good it would be for the community. But what are canonical plugins, you ask? Well, that’s one of the many things the core commit team has been talking about over the past few days, and everyone agrees that we need to prioritize this aspect of the project sooner rather than later. So, here’s a super high-level description of how we’re currently thinking about canonical plugins, which we’d like to use to initiate some focused community discussion on the topic.

Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution. These plugins would be GPL and live in the WordPress.org repo, and would be developed in close connection with WordPress core. There would be a very strong relationship between core and these plugins that ensured that a) the plugin code would be secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins prior to release to ensure compatibility. There would be a screen within the Plugins section of the WordPress admin to feature these canonical plugins as a kind of Editor’s Choice or Verified guarantee. These plugins would be a true extension of core WordPress in terms of compatibility, security and support.

In order to have a system like this, each canonical plugin’s development community would probably need similar infrastructure to WordPress itself, including things like Trac, mailing lists, support forums, etc. These things will be worked out within the development community over the coming months, but in the meantime, we really need a better name for this. Many people have no idea what canon/canonical means (clearly, they are not Dr. Who fans!), and having to define the word distracts from discussing the core ideas behind the concept. So, we thought we’d do a community poll to see what people think we should call canonical plugins. We brainstormed a few dozen ideas yesterday and whittled it down to our top handful. Based on the definition of canonical plugins given above, which of these terms do you think best describes them? I’m including a short description of our thoughts on each.

Standard - Implies that these are the standard by which all other plugins should be judged, as well as the idea of them being the default plugins.
Core - Makes the close relationship to core WordPress development very clear, and has the implication of bundled plugins (even though we don’t need to actually bundle them now that the installer is right in the admin tool).
Premium – Identifies these officially-supported plugins as best-in-class and of the highest value, and could potentially disambiguate the word Premium as it is currently being used in the community (to refer to anything from commercial support to licensing terms to actual code quality).
Validated - Focuses on the fact that the code is reviewed for compatibility with core and for security.
Official – Makes it plain that these are the plugins officially endorsed by the core team as being the best at their functions.
Canonical – Maybe once people get used to it, canonical wouldn’t confuse so many people?

Cast your vote in the poll below to have your opinion considered during the decision-making process. And if you can think of a word that we haven’t listed here that you think is better, please submit it in the poll! The poll will remain open until 11:59pm UTC Thursday, December 10, 2009.

Upcoming WordCamps

Every now and then I see someone ask in the dev channel how they can meet up with other local WordPress developers. We’re thinking about ways to make WordPress.org more of a resource to facilitate local connections, but in the meantime, I thought it might be helpful to publicize some upcoming WordCamps, the weekend conferences organized by local communities to talk about all things WordPress.

WordCamp New Zealand: Wellington, New Zealand, August 8-9, 2009

WordCamp Huntsville: Huntsville, Alabama, USA, August 15–16, 2009

WordCamp Los Angeles: Los Angeles, California, USA, September 12, 2009

WordCamp Philippines: Makati City, Philippines, September 19, 2009

WordCamp Portland: Portland, Oregon, USA, September 19-20, 2009 (Last year’s PDX WordCamp was awesome, IMO.)

WordCamp Seattle: Seattle, Washington, USA, September 26, 2009

WordCamp Birmingham: Birmingham, Alabama, USA, September 26-27, 2009

WordCamp Netherlands: Utrecht, Netherlands, October 31, 2009

WordCamp NYC: New York, New York, USA, November 14-15, 2009 (Logo contest in progress!)

WordCamp Mexico: Mexico City, Mexico, November 20, 2009

If any of these are within a reasonable distance to you, consider attending. WordCamps are a great way to meet other WordPress users, find collaborators, and expand your t-shirt collection*. I know I’ll be hitting at least a few of these; WordCamps are also a great way to get user feedback to take into consideration while we’re making decisions about what to include in core.

You can always find an up-to-date list of upcoming WordCamps at WordCamp Central. You can also try searching for WordPress groups at Meetup.com to find more regular monthly gatherings in your area.

*Most WordCamps include an event t-shirt in the registration fee.

2.9 Features Vote Results

Earlier this month, over 3500 of you responded to our survey asking you to help us prioritize some of the media features that had been suggested for the 2.9 release. While the exact features for 2.9 have not been hammered out yet, as we continue to match up developers with features, we wanted to share the survey results and let you know what we’re thinking in terms of approach.

First, the results. The first question, and the only one that was mandatory, asked what single media feature you would choose to include in version 2.9. The top vote-getter was standalone editable photo albums (as opposed to the current per-post gallery) at 17.5%, followed closely by easier embeds for videos and other third-party content at 16.5%. Next came basic image editing (such as rotating, cropping and resizing) at 13.7%, and post thumbnails (image teasers for posts featured on the home page) at 12.9%. The rest of the features each took less than ten percent of the vote. The full list came in like this:

The second question was optional (3406 people answered it), and asked you to rate each feature on a scale going from top priority down to definitely not for implementation priority. Results here were in line with the results from the first question, with most features rated as nice to have more often than anything else. The features that scored the highest in question 1 were more likely to have earned higher votes in the Top Priority column, but no feature was ranked as a Top Priority more often than it was ranked as a Nice to Have (though Media Albums, Easier Embeds and Post Thumbnails came close). The complete tabulations are shown in the chart below.

Question three was getting at the same thing, but in a more granular fashion, asking you to rank the eleven features in order of priority to you. As only one feature could be assigned to each position, this prevented people from assigning the same priority to multiple features, and we wondered if it would alter the results. Though some features got more recognition in this question, the overall rankings were still in line with the results from question 1. Here are the exact votes per feature/per position:

The fourth question asked for your preferences regarding including new media features in core, bundling them as plugins with the core download, or developing them as plugins but not bundling them with the core download. This vote was more interesting to watch. As the notice for the voting went first to the development community, then to the user community, it was possible to see a shift in the voting. Earlier in the voting cycle, there were more votes for bundling ‘core plugins’ for the advanced media features, while later votes skewed heavily toward just putting the features in core. This vote shows, I think, one of the differences between developer and user perspectives. While developers are heavily interested in keeping the core code lean and relying on plugins for advanced functionality, many users would prefer features they want to be included in core rather than being a separate plugin. The final tally on this question was 56.2% for including features in core, 38.1% for bundled plugins, and 5.7% for non-bundled plugins. The actual numbers:

Clearly this issue deserves more discussion, and the concept of how we move toward a system of canonical plugins and/or core “packages” intended for different use cases (CMS, photoblog, portfolio, etc) will be a big topic in the months ahead.

So where does that leave us regarding features coming down the road? When the vote closed, the results were discussed in the #wordpress-dev IRC chat to divvy up feature development.

The top-voted feature, standalone photo albums, is being worked on as a Google Summer of Code project by Rudolf Lai, under the mentorship of WordPress Lead Developer Mark Jaquith. The “pencils down” date for GSOC is in less than two weeks, at which point we’ll be assessing the state of Rudolf’s project. Hopefully, we’ll be able to incorporate it with 2.9 development, do some testing, amend the code and/or UI as needed, and have this launch with the 2.9 release (in core or as plugin TBD). Undoubtedly, additional functionality will be contributed by core contributors who have also been working on media plugins.

Easier embeds, the second most popular feature, is being looked at in a couple of ways. One, more shortcodes for third-party services. Work on this has already begun. In addition, Viper007Bond, of Viper’s Video Quicktags plugin fame, has taken on the task of working on a way to improve the embed experience in core. We’re not sure quite how this will work yet, but stay tuned.

Adding some basic editing functions like 90-degree rotation, cropping and resizing was considered an obvious winner in the dev chat, and as several plugins handle this functionality, we’re hopeful it will be included soon.

Post thumbnails are being handled by Mark Jaquith, who has created this functionality before, with an assist from Scribu, who has a similar plugin in the repository.

Lower ranked features aren’t off the radar, but may take lower priority than some other (non-media) features we have in the works. One of my favorite 2.9 features is in trunk now, and changes the way we delete content. Goodbye, annoying popup asking me if I’m sure I want to delete a comment/post/etc. Hello, fast and quiet removal into a trash can, from which the content can be retrieved if it was deleted by accident. Think Gmail style. We’re also hoping to work on improving page management, though that has a number of technical issues that may cause it to be a 3.0 feature instead.

As always, you can keep track of development progress in a number of ways:
1. Keep track of Trac. Contribute a patch, test a patch, just read through tickets if you have some time to kill, whatever. There are over 500 tickets against the 2.9 milestone currently. Patches and testing can help us get that number down.

2. Follow Trac commits on Twitter. Don’t want to get involved in the nitty gritty, just want to see what’s getting committed? Follow wpdevel on Twitter and you’ll get core commit updates in your stream.

3. See what’s on the dev agenda. Each week for the IRC dev chat, there’s an agenda, created based on developer suggestions posted at wpdevel.wordpress.com. This blog also contains discussions about specific development issues.

4. Join the dev chat. The day changed this week, to accommodate European schedules. Chats are now held for one hour each week on Thursday at 21:00 UTC. That’s 5pm NYC, 2pm in California, etc. Chats are in the #wordpress-dev room at irc.freenode.com.

5. Watch this blog. If you’re not a developer and prefer to stick to major announcements, the occasional survey to help decide a feature, and security notices, just keep doing what you’re doing. Reading this blog will get you all of these things.

Thanks again for your help in prioritizing features for version 2.9, hopefully coming toward the end of the year to a server near you!

Vote for 2.9 Media Features

Last Wednesday, the core development team and a number of contributing developers met in the IRC #wordpress-dev channel to talk about which features should be included in version 2.9, which is now entering the development phase. We’ve been planning to focus on media features in 2.9 for some time, and unsurprisingly, it was media features that dominated the discussion.* A large percentage of the requests we get from users are for more/better media features, so we’ve decided to focus 2.9 on building an infrastructure for improved media handling that we can continue to build on in versions to come. In that vein, we need your input to determine which features to prioritize and build sooner rather than later.

These are the features that we’re asking people to vote on (in alphabetical, not prioritized, order):

Additional Media Filters: In the uploader, you can currently upload an image from your hard drive, link to an image from a URL, or select an image from the Media Library. This proposed feature would add links in the Media Library pane that would allow you to filter images to those that had been used most recently, used most often, and/or marked as a favorite. These filters would be available on the Media Library screen as well.

Basic Image Editing: Enable cropping, resizing and 90-degree rotation of uploaded images.

Better Media Settings: Enable the creation of more default media settings controlled in the Settings section, and allow settings to be overridden  during the individual media upload process as needed.

Bulk Media Import API: Develop an API to allow for bulk media importing by plugins or importers.

Custom Image Sizes: Instead of hardcoded thumbnail, medium, large, etc. image sizes, custom image sizes would allow you to configure the maximum dimensions for each of the sizes.

Easier Embeds: Make it easier to embed third-party content such as YouTube videos, etc. Similar to Viper’s Video Quicktags plugin.

Media Albums: Ability to create and edit photo albums that can stand alone (as opposed to galleries being tied only to a post), including photostream functionality.

Media Metadata: Enable the use of categories and tags on media files.

Photostream: Create a Flickr-style photostream that simply displays images in a chronological stream (as opposed to grouping in galleries).

Post thumbnails: Choose an image to appear as a thumbnail with your post/article/excerpt.

Revised Media UI: Redesign the uploader UI to make uploading and editing media files a simpler, more user-friendly process.

These descriptions are repeated in the beginning of the voting survey, so if you forget what something means you’ll be able to scroll up to remind yourself. Only the first question (pick your top choice) is mandatory. This survey isn’t very long. Question two lets you assign a general high/low priority to each of the 11 feature suggestions, while question 3 asks you to rank the 11 features in order of priority from 1-11. A text box or two allow you to make additional suggestions, and that’s it. The survey is anonymous, and will be open all week, until Friday, July 10, 2009 at 11:59 PM UTC.

No JavaScript? Take the survey here.

Results of the survey will be used to help developers decide which features to focus on for version 2.9. The 2.9 anticipated feature list will be posted here later in July, after the priority has been determined. How many contributing developers are available to code various features will play a large part in the decision-making process, so if you’ve ever thought of contributing code to WordPress development, now’s a great time to get involved. Developer chats are held each Wednesday in the IRC channel (irc.freenode.com #wordpress-dev) at 9 PM UTC (5pm Eastern, 2pm Pacific).

* – Other non-media features that were discussed either were determined to be better held for a future version for technical reasons, or were so widely desired that they were accepted for the 2.9 roadmap without requiring a vote.