Look at the permalink on this article:

http://tech.fortune.cnn.com/2010/06/29/jeff-bezos%E2%80%99s-mission-compelling-small-publishers-to-think-big/

Yuck yuck — how do those apostrophes sneak in? Thought we would have caught this one by now.

The Unassigned milestone has been renamed to Awaiting Review. (If Trac gives you any “Invalid Milestone Name” errors, just refresh.)

Additionally, all open tickets in the 3.1 milestone have been moved to a temporary Awaiting Triage milestone, to enable us to re-sort these without mixing these in with new tickets coming in, to ensure new tickets are reviewed as soon as possible after submission.

Per our timeline, 3.1 now says active development will begin in September 2010.

Suggest topics for the July 1, 2010 dev chat agenda.

Agenda for June 24 developer chat.

• Review of 3.0 feedback – incoming ticket rate, common issues, etc. – All
• Trac Changes – Nacin/Mark
• Next steps: 3.org and 3.1 – All

Hiatus

This post is meant as prep for the IRC dev chat taking place in about 3 hours, *not* as an official done deal announcement/dictate/decision, so please take it in the spirit in which it’s being offered. This is how we think it should work, and after the dev chat we’ll do a gut check to see if it still makes sense.

“We’re taking a dev cycle off after 3.0 to focus on the wordpress.org site, plugins, and community improvements.” Ever since that idea was put forth, there have been people wildly in favor and wildly opposed. Let’s all relax a little. Here’s the general thinking of the core team:

• Take a two month hiatus from core before beginning discussion of scope for/development on version 3.1. Obviously, security fixes and/or major bugs would still get a point release if needed in that time.
• Identify a handful of projects that can be completed in 2 months that would make the WordPress experience appreciably better, whether it’s related to support, plugin developer infrastructure, or anything else. Taking comments on this in the forums at this thread.
• Identify contributors who want to be part of this effort and are willing to make a specific time commitment of x hours per week for two months, as well as which mini-projects most appeal to them.
• Put together teams from the volunteers, small ninja/pirate teams of 3-5 developers who can crank out code like [insert a metaphor better than the one that came to mind for me, 'cranking out spaghetti from a pasta maker,' which is terrible]. Add a consulting member of the UI working group so things all work/look consistent. Add a lead/commit-level dev to each team to guide the project.
• Have each team agree to the scope of its project, create a timeline for the 2 months, and start by writing an announcement post for their improvement (this helps focus the scope and gives you a tangible goal for completion).
• We’ll give team members author rights on this blog, and each team will post an update at least once per week, using the tag that we identify for the project, so interested community members can follow along with the project feeds.
• Launch improvements as they are finished (they don’t all need to wait until 2 months have elapsed).
• Bask in glow of appreciative WordPress community and your own heightened sense of awesomeness for volunteering your time and being a part of something bigger than yourself that affects tens of millions of people on a daily basis.

Think of it like the hiatus that TV actors take in between seasons: just long enough to do a movie and get re-inspired to tackle the next season’s character blah blah blah. This will only work if we really stick to our guns and focus on .org projects; if we’re debating things all over trac at the same time, attention will be divided and we won’t accomplish the goals of the two month project sprint.

This can also serve as an experiment in forming mini-dev teams for discrete projects, which is something that has been discussed as maybe worth trying for core feature development.

We’ll discuss all this in the dev chat today. After the dev chat is over, people interested in participating in the 2-month .org project sprint should leave a comment on this post. We’ll organize it kind of like we did for choosing GSoC students and mentors: Identify your most useful/relevant dev skills, what potential projects you would most like to be involved with, if there’s anyone you’re particularly interested in collaborating with, etc. On Monday we’ll see what we’ve got and try to put together some appropriate teams.

The more we can approach this experiment with a positive attitude, the more likely it is to succeed.

I’m seeing web services I use start to celebrate HTML5 features, and for them to garner some mindshare.
http://www.html5rocks.com/ is regularly referenced.

We should strive for this level of detail improvement in every release of WordPress:

http://nikf.org/post/722500438/8-subtle-changes-you-may-or-may-not-notice-in-ios-4

The ability to set “priority” and “milestone” for WordPress Core Trac tickets has been restricted. Unknown Trac users will not be able to set them when creating or updating tickets. These fields were being somewhat misused by casual Trac users — e.g. setting priority higher than it should be, or sticking things in the 3.0 milestone when 3.0 was in RC. We are adding the ability to set these fields to known WP contributors based on frequency and quality of code and ticket contributions. That list is not complete, so don’t micro-analyze the inclusion or non-inclusion of anyone at this point!

This should help WordPress avoid having hundreds of tickets on a milestone that need to be punted in the weeks before release. We can be more judicious in assigning a milestone to a ticket.

Suggest Agenda Items for 24th June 2010 dev chat

We’re skipping the dev chat this week. Resumes next week.