The UFO Blog

Author Archive

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!

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.

var PDF_surveyID = ‘2F95783C8744F81A’;
var PDF_openText = ‘Vote now!’;

Vote now!

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.

“I wish they’d implement feature x.”

“Why won’t they put feature y into core? It’s rated really high in the Ideas forum!”

“It doesn’t matter what I think, all the decisions get made by an elite crime-fighting squad funded by an anonymous millionaire. Er, I mean the four core devs.”

These sentiments, and others like them, are the focus of today’s post. Setting aside the similarities between Ryan, Andrew, Mark and Peter to Charlie’s Angels for a moment, the question of how decisions about features are made needs to be addressed. There are a number of mechanisms in place for communication between the community and the core team, but with so many different channels, it’s hard to keep up with them all and still focus on production. Here’s where we are now…

#wordpress-dev IRC channel: The IRC channel used to be more active. These days there’s rarely more than a dozen or two people online at any given time, and hours go by with no activity. When a question pops up, it’s often a tech question from a less experienced developer or site manager looking for help, as opposed to ongoing discussions about the best way to approach core code and features. When core-focused discussions do occur, they tend to fade out as time zone variances cause people to log off before a core dev enters the room.

wp-hackers list: The hackers mailing list reaches thousands of contributing developers, plugin developers, and lurking interested parties. Discussions range from how to use hooks to whether or not something in core should be changed to troubleshooting for other list members. Conversations on this list sometimes can get heated and occasionally stray into rudeness, which makes some people hesitate to utilize this communication channel.

This dev blog: This blog is used mostly for “official” announcements, and more recently, for surveys and polls intended to give the core devs an idea of community opinion on things being considered for future versions. Posting is irregular, sometimes with new content every other day, sometimes with nothing for a couple of weeks.

wpdevel.wordpress.com: Another blog, also an “official” outlet, in which the core team posts about any big code changes they’re working on. This gives plugin authors and contributing developers a heads-up, and provides a place for community discussion around specific issues like the new widgets API.

Trac: The ticket system used for active development has gotten out of control. Hundreds of tickets are already lined up for future versions because they were punted from current releases; many aren’t even relevant anymore. Trac has wound being a place where people report bugs, suggest code changes, request features and debate methodologies; some of these conversations are years old. This broad use of the system makes it harder to power through tickets and get bugs fixed.

Ideas forum: The Ideas forum is a place where anyone can suggest a new feature, rate features suggested by others, leave comments, and generally discuss the future of the WordPress application. However, like Trac, some of the items here are years old. Because of the way the rating system works, older items remain at the top of the list. Some threads are simply he said/she said preference arguments, as opposed to contructive discussions about the value of implementing certain features or changes. There’s no direct connection between the Ideas forum and Trac.

WordPress is an open source project, successful because of the community that both develops and uses it. At the same time, some people find it difficult to become involved in the project, and are unsure of how to engage with the core team and community at large. The channels listed above can be overwhleming to someone just joining the community, and/or frustrating to longtime community members who feel like they used to have more influence. We need to fix this. The WordPress project needs to be welcoming, easy to navigate as a contributor, and provide useful feedback to help grow the expertise of its community members.

I think we should figure this out together. You, members of this community, know how you feel about the communication channels available to you. You probably have ideas about how to make it better. Some of you may even have sketched out digrams of systems that you think would work better.  Link Ideas to Trac? Change the Ideas rating algorithm? Close Trac tickets that don’t get resolved within a certain period of time? Just do everything through Trac? What do you think? What would make it easier for you to keep up with development progress and get involved with the varius contribution opportunities? I *know* you have an opinion.

Over the next few weeks, we’ll be gathering your input about how we can improve communication and participation, and then we’ll embark on a project to fix/create a system for collecting ideas, opinions and feedback that will allow WordPress to grow as an inclusive community. Here’s the plan: Gather ideas from people via IRC, forums, live chats, surveys, etc. Assemble a small group of interested parties to help figure out possible approaches, put suggested approaches to a community vote. If redesigning something (like the Ideas forum) is deemed necessary, utilize community designers to create layouts. Beta test it to see if it does work as hoped. Launch and make everyone happy with the new, improved communication/ideas/feedback system!

Up First

Use this forum thread to post your suggestions about this. What do you think needs to be changed or improved? How would you structure it? How do the existing channels fit into your suggestion?

On Tuesday, May 12 at 21:00 UTC (5pm New York time), hop into the #wordpress-dev IRC channel (irc.freenode.com) and talk about your suggestions for how to improve communication. I’ll be there, taking notes and answering questions, and asking follow-up questions when someone pitches a good idea. An hour later, I’ll be joining the WordCast Podcast to talk about this issue. They’re trying to set up a call-in format; if that pans out, we’ll post the call-in info in the dev channel. Otherwise, A call-in number has been set up through TalkShoe.

1-724-444-7444
Meeting ID: 50127
Pin (if you don’t have a TalkShoe account): enter 1#

We’ll also read off suggestions being made in the dev channel and discuss them.

More opportunities to weigh in on this issue to come. Also, further investigation into the similarities between the core devs and Charlie’s Angels.

One of the reasons WordPress 2.7 was such a success is the amount of usability testing that took place during the development cycle. Starting with testing 2.5 and the Crazyhorse prototype and following with the 2.7 beta, the testing program looked at almost every feature and function in the application. That kind of thing? Takes a lot of time.

For readers who aren’t familiar with the process behind usability testing, here’s an overview. First, determine the scope of your test and create a test protocol/script. Determine the audience segments to be included in the test group(s), and begin recruiting. Recruiting may mean hiring an agency to find participants, but for testing WordPress, it makes more sense to recruit from within this community, so that means making a screening survey, reading all the responses, segmenting the respondents into categories and contacting people until you’ve filled your desired quotas (for whatever segments you’re seeking, such as newbie, experienced user, developer, CMS user, photoblogger, mobile user, etc. ). Then come the test sessions.

Depending on what is being tested, these last anywhere from half an hour to an hour and half apiece. Sessions are generally recorded using screen capture and web cam, with a video camera for backup. The moderator(s) generally take notes during sessions and/or (depending on what software is being used for the session capture) set markers in the video to indicate task completion, comments of interest, etc.  In some cases, auxiliary test methods such as eye-tracking may be included. When the sessions are complete, the results are analyzed. All the notes and videos are reviewed, patterns are identified, and ultimately a report is written and the feedback informs the next round of revisions.

Some people think it shouldn’t take much time to do all this. I’ve lost count of the number of people who cite an old article by Jakob Nielsen that says you don’t need to test with more than 5 users because usability issues become clear right away. While I’ve found that to be generally true, when your user base is as diverse in experience level, usage, platform  configuration, language (right to left languages have a pretty different experience) and demography as the WordPress community is, 5 users really isn’t enough to get a clear picture. We try to test with at least a dozen people each round, but then we are limited to a geographic region (test in NY, test in SF, or test wherever we can schedule enough people back to back to make it worthwhile), while WordPress users are located all over the globe.

To address this, we’re introducing a set of new contribution opportunities to expand our usability testing program. As with development and graphic design, we’re going to create an infrastructure to allow community participation in usability testing on a regular basis and in a much broader capacity than existed before, when it was limited to announcements that we needed participants in x city on y date. We’ll be looking for volunteer moderators as well as participants, hopefully from all over the world.

Moderators. Observational usability testing isn’t rocket science, but neither is it a simple task to reduce bias. Because of this, at first we’ll choose only moderators who have professional experience conducting usability tests. People who conduct testing for design agencies, software companies, usability consulting firms and the like will be our first round draft picks. In the future, when we have a group of regular volunteers and have ironed out any kinks in the process, we’ll ideally match up experienced testers with aspiring ones, using a mentorship model to increase the number of people who can contribute in this fashion.

Participants. If you use WordPress, chances are you could participant in a usability test at some point. In some cases we’re looking for particular behaviors (people who upload large video files, people who blog from their iPhone, people who manage more than 5 blogs, etc.), while other times the behaviors we’re looking for are much more common (do you have widgets in your sidebar, have you changed themes in the last 6 months, is there more than one author on your blog, etc.).

So how will these opportunities come into play, and how will it make WordPress better?

We’ll start with the moderators, and try to get volunteers with a decent geographic spread. Then, we’ll start signing up potential test participants in those areas (though we’ll also allow at-large registrations, since traveling testing will still be happening). We’re working on a registration process for potential participants. You’ll enter your basic info (location, contact info) and answer some questions about your WordPress usage to be entered in the database, and when there’s a testing opportunity coming up that’s appropriate for you, a local moderator will get in touch to see if you’re interested. Further down the road we may experiment with remote testing and other methods, but for now, this approach will broaden the geographic scope of our testing.

All moderators will follow the same test protocols and script, and their results/reports/video will be reviewed and collated, with a composite report (including the protocol/script that was used) published to the community. This will provide designers and developers with broader feedback during the dev cycle, and will allow the wider community to both understand and participate in the testing program.

If you’re interested in being a moderator during this initial phase (meaning you do it professionally), send me an email and introduce yourself. If you’re interested in signing up as a potential test participant, watch this space. We’ll post a link to the registration survey once it’s ready.

The poll is closed, the votes are counted, and the results are interesting. The table below shows the actual breakdown of the poll votes, of which there were 2,651. As you can see, there were four main contenders: Dean J. Robinson’s Fluency-based submissions (two variations), the existing 2.7 interface, and Matt Thomas’s comp (MT), which exists somewhere between them in terms of style. Note: GB was a late entry, and was posted after over 900 votes had already been collected.

As several people have rightly pointed out, the Fluency-style designs not only took the top spot, but in combination added up to a higher percentage than any other. We’re not focusing solely on that statistic, though, because had other designers submitted multiple versions, the numbers might have looked different. What was most interesting for me was checking in on the votes over the course of the two days the poll was open. The top three (Fluency-dark, Current 2.7, MT) kept beating each other out for the #1 spot as they cycled back and forth through the top three slots, and had the poll closed on time (left it open a little longer in case anyone translated the time zone incorrectly), the order would have been a bit different.

What’s more interesting to me is the overall style that seems to be preferred among voters, as Matt’s comp has some stylistic similarities to Dean’s (see image at left). It also would be interesting to know how many of the votes for the current 2.7 interface were based on thinking it looked the best vs. how many were votes against changing the interface at all so soon after the 2.7 redesign. If you want to comment on what you liked best and/or least about any of the designs, this thread is a good place.

So what happens now? However we look at it, the Fluency-style designs clearly have a lot of fans. Then again, so do the designs of Matt Thomas (he’s behind the current style of 2.7, remember, in addition to the comp labeled MT). To give the interface the attention it is due, and to take seriously some of the interface feedback around usability and accessibility, we’re going to leave the looks alone for 2.8. It’s our guess that a revised style will make into 2.9 early in the development cycle to allow us plenty of time for user testing and revision. How close it winds up being to the comps submitted in this design tweaks challenge will depend, but in the meantime:

Congratulations, Dean J. Robinson, on winning the vote!

Comps for the header/nav design tweaks are in, and the results are mixed. Some people just moved a few things around, while others proposed a new style altogether. We won’t make any major changes to style in 2.8, but if the vote leans toward a submission that proposes it, we’ll do some user testing and make a decision for early 2.9 (which, now that we think of it, is probably the right thing to do anyway. )

Below are the links to the screenshots that were submitted. Please review each one (I’d open them all in tabs so I could look back and forth while they are all large size, because the voting poll just uses thumbnails), then choose the one you think looks the best/is the most usable.

This poll was supposed to close at 8pm NY time on Tuesday (today), but we’re going to leave it open for an extra day. The voting poll will now be closed at 8pm NY time on Wednesday (that’s 2am Thursday, UTC). If you want to discuss the entries’ pros/cons, this thread would be a good place.

Current: The existing interface, for reference

KM: Current nav, header elements moved

AN: Current nav, file folder style header

KD: Current nav, modified header style

JJ: Swap blog title and favorites menu

DR1: Fluency style, dark

DR2: Fluency style, medium

DR3: Fluency style, light

IK: Nav layered over dark background

GB: Modified nav/header intersection

MT: Modified nav and header

Results will be posted the day after the polls close.

ACT I

Jane: It is a thorn in my side that the blog name header is above the “dashboard” nav section in the admin, since in MU installations and with plugins (like stats), things in the Dashboard section span multiple blogs. Makes more sense for the header to head only the per-blog content area.

Mark: I agree about the header. “This is the menu, this is the content.”

All: Yep.

Five minutes later…

Mark: What do you guys this of this quick mockup I just did, playing with the admin header?

Jane: I like it that the nav is not under the header. Might need some styling help. I was also thinking maybe the favorites menu should drop down into the white h2 area by screen options/help tabs.

Ryan: Menu color to the top with blog title pushed over and favorites next to screen options sounds quite nice.

Jane: I’ll ask Matt Thomas if he could style it [ed. note: Matt Thomas created the visual style for 2.7], and we can see what people think, maybe post on wpdevel for feedback.

Ryan: If it’s quick, maybe we could even get it into 2.8.

ACT II

Matt T: Here are some comps based on what you told me.

Jane: Cool, but where are Screen Options and Help tabs?

Matt T: Still working on that.

Jane: Hm. Wonder if there’s time to open this up to community designers? I know we’re in freeze, and it’s no notice, but you didn’t get any notice either when we dropped this styling request on your lap a few hours ago. That’s the way open software development works: sometimes the best ideas come at the last minute!

Matt T: I’m all for letting the community take a stab at it. Especially if they come up with something brilliant to do with the Screen Options and Help tabs.

Jane: I’ll ask Ryan about release date and see if there’s time. I know they wanted your style recommendations today.

Act III

Ryan: Tuesday is probably doable, no later than that for final delivery of style and any gradient graphics, etc.

Jane: Awesome! People will hate me for the short notice after the has-patch marathon, but since it’s a small project and over the weekend, and wasn’t even something anyone was planning until a few hours ago, I’m *really hoping* people will take this for what it is, an attempt to give more people input into an upcoming visual change in the interface, even if it’s not a huge one.

Ryan: Would have the benefit of warning people that header and menu will be changed a bit.

Jane: And we can have a vote. If I can get all the materials together and post in the morning, that would give 2 days of design time for submissions on Monday, and if we do a day of voting Tuesday, that’s 3 days notice for the vote. I’ll make sure to post to all the lists, etc.

Ryan: Will we announce with comps from Matt T as examples of what we’re thinking?

Jane: I’ll write up the UX reasons for considering the change, and Matt T can provide some style guidelines and his original comps so no one will have to waste time mocking up the basic screen layout.

Ryan: That would help set the scope. We just want tweaks here and there, given the timing.

Jane: Woot!

On Your Mark, Get Set…
Okay, so here’s the deal. Modifying the nav/header to be a little nicer is was a last-minute design idea, and if it can’t be worked out in the time we have left before 2.8 (which is very little), we’ll just wait until 2.9 to work on it. But! If someone comes up with something the community really likes and it doesn’t break any of the design guidelines for the rest of WordPress, we could sneak it in.

UX and design guidelines for this mini-project are posted here (so as not to clog up anyone’s feed reader with big graphics). Read through the UX stuff, check out the comps Matt Thomas mocked up last night (with absolutely no notice, for the record). Use the .psd as your base, and when it’s time to submit your ideas, make a .jpg or .png and post a link to it in the comments on this post. (Note: Only comments containing a link to a design submission using this format will be approved. For general discussion about this design challenge or any of the submissions, please head into the #wordpress-dev IRC channel.)

Submit the link to your comps by 1am Tuesday, April 28 UTC (7pm Monday, April 27, New York time). If you have questions or want early feedback, we’ll be in and out of the #wordpress-dev IRC channel between now and then.

Once we’ve received the submissions, we’ll post a voting survey (much simpler than the icon survey; this one will be more of poll, just choose the one you like best) as soon as possible, and will post the link to it here as soon as it’s online. We’ll only keep voting open for one day because of the 2.8 deadline, so put it on your calendar if you think you’ll forget. Voting will close at 2am Wednesday, April 29 UTC (8pm Tuesday, April 28, New York time). Results will be announced the following day.

Go!

* Chats above are a conglomeration of actual chats.

Reminder: Only comments containing a link to a design submission will be published here. All other comments will be deleted.

If you want to leave a public comment about this contest, the design, etc., I’ve created a thread in the forums that you can use. Please discuss these things there. If you leave a regular comment here on this blog, no one will be able to reply to you, because only actual links to design submissions will be posted in the comments here.

Google has announced the successful applicants for the 2009 Google Summer of Code, and WordPress is lucky enough to have eight students allotted to our open source project. It was a tough choice, since we had almost 60 applications to choose from. We’d like to thank all the students who applied, and we’re sorry we couldn’t take on more of you.

Developers, if you see these bright young things in the dev channel, please be your usual friendly, helpful selves. Everyone else, wish our students luck with their projects this summer, which promise to be challenging but awesome. Without further ado, I’m pleased to introduce the GSoC projects (in no particular order) and the students tackling them.

Justin Shreve, Extended WordPress Search Engine. Justin will be mentored by Andy Skelton. One of the complaints I hear over and over again is about the search engine, so this could have great benefit to WordPress core.

Rudolf Cheuk Sang Lai, Adding Photo Grouping by Album Functionality. This project will wind up being a piece of a larger media redux project for 2.9/3.0. Mark Jaquith is mentoring, and Noel Jackson will be a backup mentor.

Daryl Koopersmith, WYSIWYG theme editor/generator. This will allow users to create and edit themes without touching any code. Beau Lebens is the mentor on this project.

Michael Benedict Arul will be working on a similar project. Michael will be mentored by Andrew Ozz, since this project will be using jQuery. It’s our hope that having two students working on this idea separately will foster competition and allow us to compare approaches.

Daniel Larkin, Modified Preorder Tree Transversal (MPTT). Lead Developer Ryan Boren will be his mentor. This is Daniel’s second GSoC working on WordPress.

Diego Caro, a student from Chile, will also work on an MPTT project. Diego will be mentored by Thorsten Ott.

César Rodas, social and text processing algorithms for BuddyPress and MU as related to recommendation engines. Alex Shiels and Andy Peatling will co-mentor this project.

Anthony Cole, Event management with WordPress. Co-organizer of WordCamp Australia and New Zealand, Anthony will be working on a suite of plugins (or maybe just one or two out of a planned set, scope TBD) for event management/attendee networking that will be built on BuddyPress/MU/bbPress. We’ll use wordcamp.org as a test case, and release the final product to the community. Jake Spurlock will be mentoring, with Andy Peatling as backup.

Congratulations, guys*!

*Seriously, we didn’t get applications from female student developers. Where are all the geek girls?

As promised, here are the results of the 24-hour has-patch marathon that was announced, begun and completed over the course of a few days last week (more on timing after the results). Results include activity from 8am Pacific time on Thursday, April 16, 2009 to 9am Pacific time on Friday, April 17, 2009.

Total number of patches committed to core: 44

Contributors whose old patches were committed: 9

Marathon contributors whose patches were committed: 13

Tickets closed: 102 (breakdown below)

• Fixed – 45
• Dupe – 16
• Wontfix – 10
• Invalid – 19
• Worksforme – 12

Tickets created: 20 [I guess not everyone got the memo that we were trying to close tickets. ]

Tickets reopened: 4

Number of testers who left comments in ticket threads: 10

Number of testing-specific comments: 18

These numbers are based on opening each ticket that registered activity during the marathon hours and counting the actual comments that indicated some testing of a patch. Contributions to philosophical discussions without a patch, while important, weren’t counted for this purpose. Nor were Trac notices that simply noted a ticket was being closed because it was a dupe, invalid, etc.

Top five contributors (committed patches): Denis-de-Bernardy, filosofo, nbachiyski, scohoust, simonwheatley

Top five testing feedback providers: shanef, Nicholas91, Denis-de-Bernardy, sivel, williamsba, mrmist (tie)

Given the short notice/last-minute nature of the marathon, I think we did pretty well. Granted, there were people who complained that two days wasn’t enough notice to clear their schedules, but let’s be honest, the 24-hour has-patch marathon was more of a rallying cry to help clean out Trac than a deadline based on anything specific. Patches are always welcome/encouraged, and now that the big features for 2.8 are mostly done, the lead devs will be able to spend more time reviewing Trac tickets and patches. Still, not too many people tested existing patches (or if they did, they failed to leave the requisite comment in the ticket threads). Testing patches is one of the easiest things you can do to help further development, since patches won’t be committed or rejected until they’ve been tested by several people.

As we get closer to the 2.8 release, jump into Trac any time and test a few patches (don’t forget to leave the feedback!) if you have time. If there’s a ticket you’re sick of seeing there, write a patch and ask your fellow contributors to test it and comment on the ticket thread. We’ll announce an official bug hunt soon (and yes, there will be more than two days’ notice), but the fact remains that addressing new bugs is easier if Trac isn’t clogged with old tickets. If you spot duplicate tickets, mark it a dupe, note the other ticket number in the comments and close the ticket. If you see one that is no longer relevant because the current code base fixes a problem reported several versions ago, mark it invalid, leave a comment and close the ticket. These simple housekeeping tasks may not seem like much, but they do help. Special props to Denis-de-Bernardy, who in addition to writing a couple of patches during the marathon and testing a few others, did a bunch of ticket maintenance like this, and cleared out a number of tickets.

Thank you to everyone who participated, and until the next marathon, happy patching and testing!

Te 24-hour has-patch marathon has just officially begun! For the next 24 hours (until Friday, 4pm UTC), the core developers will be evaluating patches that have been tested and committing those that are good. When they run out of those, they’ll start testing patches that have been submitted but not tested. This takes longer, so help us keep the momentum going by testing patches today.

Grab yourself a copy of the nightly build to make sure you’re using the right version, then head over to Trac and start looking at the has-patch* tickets. Pick a ticket, download the diff, test it out on the browsers/platforms you have available, and write a comment about the results in the ticket’s comment thread. Move on to the next ticket. Do as many as you can over the next 24 hours.

And if you’ve got the mad skills to contribute bug fixes and code patches for enhancements and other tickets, now is also a great time to contribute a patch. Why wait? One of the complaints I hear in the IRC #wordpress-dev channel is that it can be frustrating to write patches because sometimes it takes a long time for them to be reviewed and committed. For those people (and everyone else), this is the perfect time to patch, because we’ll be looking at every has-patch ticket in Trac for 2.8 over the next 24 hours. If you have a patch that’s been submitted but it hasn’t been tested, consider doing a little PR for yourself. Hop in the dev channel, post on your blog, mention on Twitter that you need people to test your patch *today* so that it can move forward in the process. This will speed things along. You can also add the keyword needs-testing in addition to has-patch.

At the end of the 24-hour period, you don’t have to put your pencils down, but the core devs will be going to sleep and then returning to the regular dev cycle, so it’s worth it to contribute today. If you miss the deadline, it’s okay; you can contribute or test patches as usual, you just won’t get the more immediate gratification the marathon promises.

We’ll post the results of the marathon here on Monday, after everyone’s gotten some rest and we can go through the Trac logs to see how many people got involved. This is one reason it’s so important to leave a comment when testing patches…it’s how we’ll be counting the number of marathon testers. Top patch contributors and testers will be recognized in the results post, so if that sort of thing motivates you, let the link love lead the way.

Of note: we are now in feature freeze for 2.8!

* – For those who don’t know why I keep using the term has-patch… When someone submits a patch by uploading it to the Trac ticket, they add “has-patch” to the keywords field, so that the core devs will know there’s a patch attached. Not the most elegant system, true, and you’d think maybe Trac could just recognize that a certain file type had been uploaded, but there you have it.