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 Traversal (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 more than a couple of 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!

The 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.

Waiting patiently for a bug hunt to be announced before you get involved as a WordPress development contributor? Pshaw! Don’t be shy!

2.8 currently has about 500 active tickets that need to be resolved. The core devs are largely working on the bigger feature additions, such as the embedded theme browser/installer, the new widgets management, improving performance, etc. so a lot of tickets that are of lesser priority are still just sitting there. Aren’t they calling to you, just like puppies at the pound? “Adopt me! Please!”

Before we have a bug hunt and see the addition of dozens of new tickets, we need to clear out some of these old ones. Not being the kind of shelter that euthanizes its bugs after a certain amount of time (seriously, there’s one ticket that goes all the way back to version 1.5), we are hoping people will step up and bring home a bug today.

To keep things moving, we’re announcing a new kind of event, related to bug hunts, but with a different slant. We need a sprint to clear out these tickets. Thursday is the day (and Friday for those over the date line). Core devs will spend 24 hours going through all the tickets tagged with has-patch, and committing those that have been tested and work. So how can you get in on the Super-Awesome WordPress 24-Hour Has-Patch Marathon?

Write a patch. There are dozens of tickets for discrete little pieces of correction (change … to actual ellipses in admin interface, change the ‘go back’ link to a ‘view page’ link, etc.), dozens that are browser-specific bugs, dozens that might be more challenging. Pick the one you want to work on, add a comment to the thread so other marathon contributors know someone is working on it, and get the patch submitted before the marathon ends. If you start coding now, your patch could be in by the weekend!

Test a patch. There are, as of right now, 177 tickets marked with has-patch. Patches can’t be committed until they’ve been thoroughly tested. If you’re already running the nightly build start testing out these patches in as many operating system/browser combinations as you have. Only have one? Hey, it’s probably more than has been tested already! If you’re not already running the nightly build, you can download it here to set up a test blog. Don’t forget to add what you found to the comment thread for each ticket. If it doesn’t work, be specific about what is not working so that others can jump in and fix it.

24 hours of patching, 24 hours of testing, 24 hours of committing. Don’t miss the excitement; get started now!

The Super-Awesome WordPress 24-Hour Has-Patch Marathon begins Thursday, April 16 at 8am Pacific time (that’s Thursday, 4pm UTC) and will end, as you might have guessed, 24 hours later. No reason to wait, though… start early and get patching/testing. The more patches that have been tested by Thursday morning, the more that will be committed during the marathon.

Go WordPress!

As mentioned previously, the icon design contest was such a success that we realized we needed to create more ways for graphic designers to contribute to the WordPress open source project. Our community is chock full of talent, and this talent is just itching to get involved. So, we’re trying out a few ideas.

First and most immediate is the creation of a new “component” in Trac for graphic design. We’ll use this component label to create tickets for things like making graphic buttons, such as making a new version of the favorites menu graphic or WordPress mark that looks better with the blue admin theme. In some cases graphic design tasks will overlap with CSS tasks, so designers interested in contributing can search for open tickets with either component label. In cases where a base PSD file is needed as a starting point, we will attach it to the ticket.

In this vein, if you notice a graphic that needs fixing (like the aforementioned favorites menu button needing a blue version), please use the graphic design component label to report it in Trac. Please don’t create tickets for graphic you just don’t like… keep it to things that look broken or overlooked.

Graphic design tasks will follow the same protocol as development tasks in that volunteer work will be overseen/curated by the core team. Both Matt Thomas (who provided the art direction for 2.7) and I will work with the core development team to identify design tasks and review submissions (i.e., we’ll make sure things look awesome before they’re committed). We’ve been trying this process with an early volunteer, and it seems to be working well. In addition to creating individual Trac tickets, if a project arises that requires many graphic elements to be created, we will post about it here on the dev blog to give potential contributors a heads up.

The second opportunity for graphic design contributions will be less about discrete tasks and more about contributing to the evolving visual design of WordPress. When there are larger design tasks in the works, such as creating an admin theme or designing the new media upload process, there will be opportunities for screen design. In these situations, potential contributors will be given access to materials such as wireframes or specifications and will be able to submit comps of design approaches. In the event that we receive multiple good submissions for a screen design, we will use a community vote to influence the final selection, as we did with the icon design contest.

Since 2.8 is wrapping up currently, there aren’t many design tasks waiting to be completed right now, but when we roll into 2.9 development, there will be more opportunities for graphic designers to get involved.

Students, secure your awesome summer by applying to the WordPress Summer of Code now! The deadline is in 3 hours, 12 noon PDT / 19:00 UTC.

Be like Billy.

Dad: Well, Billy, another school year is coming to a close. No more college parties, just another summer here at home. What will you do all day?

Billy: Oh, I dunno. I’ll probably work on my blog or something.

Dad: You need more direction! That blog is just your generation’s answer to comic books.

Billy: On the contrary, Dad, working on my blog utilizes my skills in programming, design, writing, critical thinking, and all sorts of other liberal artsy things that you’re paying those professors to teach me.

Dad: If only there were a more practical application for those skills, one that could lead you to fame and fortune!

Billy: Where’ve you been living, Dad? My skills are totally in demand in today’s questionable economy. An awesome WordPress developer is worth his/her weight in gold. Lead, even.

Dad: What is this WordPress?

Billy: Only the greatest open source publishing platform ever created. It’s what runs my blog. I like to fiddle around with the code and come up with cool hacks that make mine better than the average College Joe’s.

Dad: I had no idea you were that capable.

Billy: Duh, Dad. I’ve been using WordPress for a couple of years now. I could practically teach a course on it, though there are definitely things I could learn from the lead devs. They are like kings.

Dad: Hm. That kind of ability ought to be worth something. Seems like there would be programs in place for kids like you to utilize your skills while being nurtured  by people like these lead kings.

Billy: Lead devs, Dad. Not lead kings.

Dad: Maybe you could apply for an internship or something, earn a little money this summer instead of just spending mine.

Billy: Well, there is this one thing like that.

Dad perks up.

Billy: The Google Summer of Code lets college students work with lead developers on a bunch of open source projects, you can get college credit for it, and if you do a good job, you can earn up to forty-five hundred bucks over the summer. And WordPress is one of the participating projects.

Dad: !!

Billy: But it’s pretty competitive. My friend Joe applied last year and didn’t make the cut. I can improve my skills just by fiddling around on my own this summer without the rejection, thanks.

Dad: Don’t be lame! You said yourself you’re awesome. And that you could learn from the kings. And that you could earn over FOUR THOUSAND DOLLARS. Life is full of rejection, kid. Best way to get over that is to make yourself so awesome that no one wants to reject you. And know that even if they do reject you, there’s always next time.

Billy: I dunno, Dad.

Dad: Tell you what, if you apply, I’ll give you $500 toward that car you’ve been wanting, whether you’re accepted into the program or not. And if you get in and complete it successfully, I’ll match that $4500. I’d be so proud of you. And the bragging rights at work! My kid, a Google engineer!

Billy: I wouldn’t actually be a Google engineer, Dad.

Dad: Oh be quiet. Do you think Harold in shipping knows the difference?

Billy: Okay, Dad, I’ll do it!

Dad: That’s my boy.

…………………….

College students! Don’t wait for your parents to bribe you; apply to the Google Summer of Code program now! For the third year in a row, WordPress is participating, and this year we’ve got project suggestions ranging from core functionality to plugins and BuddyPress development. You name it, we want you to propose it. It’s true, competition is fierce, but hey, if you’re already hacking WordPress, you’re ahead of the pack as far as we’re concerned. Applications are being accepted as of today, and the deadline is on April 3, 2009. For more information, check out the WordPress Codex GSoC2009 page, where we suggest some projects and let you know who our kingly mentors will be this year. The GSoC FAQ is also a good place to get an overview of the program. To apply, head to the Google Summer of Code application site. Remember, we want *you* to work on WordPress this summer! And College Janes, this isn’t just for College Joes. Female applicants encouraged to apply!

A week or two ago at WordCamp Denver, I gave a presentation about some plans to create more opportunities for people to contribute to the WordPress open source project. The icon design contest was such a success that it seems clear we need to come up with ways for non-developers to contribute their talents and skills to WordPress. Since the launch of 2.7, we’ve been working out what kinds of contribution opportunities would make sense, and we’ve come up with a handful.

This (long) weekend, many WordPress users and developers (including half the core team) will be in Austin, TX for South by Southwest. Matt Mullenweg, Ryan Boren, Mark Jaquith and I will all be there, so say hello if you’re there, too. In the spirit of all this WordPress community connecting, I’ll be posting here every day during after SxSW with information about the new contribution opportunities we’re creating. Each post will cover one or more of the following:

• Development (of course)
• QA
• Documentation
• Ideas and Opinions
• User Experience
• Graphic Design
• Accessibility
• Usability Testing
• WordPress.tv
• Community Organizing

Since the first thing people think of when they think of contributing to WordPress is PHP development, we’ll start there.

The code (which is poetry) is the meat of the application, so it makes sense that the most opportunities to contribute will continue to fall in this area. Trac is always filled with tickets that need patches, patches that need testing, and issues that need some creative developer thinking/collaboration to find the right solution to a problem that has us going in circles.

If you are proficient in PHP, consider looking through the tickets (especially the ones marked “bug,” since they should get higher priority) and writing a patch for one of them. If you’ve got more advanced skills, consider writing a patch for one of the more complex tickets, or offering corrections to a patch submitted by someone else (if needed). If you don’t trust your coding skills but know your way around the application files, look for tickets tagged has-patch and test the patches in as many browsers as you can, posting your results afterward in the ticket thread.

If you find a bug in the course of your daily use of WordPress, report it. First, check Trac to see if the issue already has a ticket. You could also scan the archives of the wp-testers list to see if people have been talking about the bug, or email the list yourself to see if anyone has any information on the problem. If these actions don’t bear fruit, start a new ticket in Trac (you’ll need to create a login to do this). Be as detailed as you can about the issue, and don’t forget to make the proper selections from the metadata dropdown menus. Just in case anyone is unsure of how to make these selections…

Use the severity field with caution. Most bugs will be of normal severity. Marking a bug as high severity will not necessarily speed up development, and if it turns out that you’ve marked a bug’s severity incorrectly it may even slow down development.

Priority will usually be normal. Leave it to the more senior developers to change the status to a higher priority, as they are familiar with all the tickets and Trac and will be better able to assess the priority in relation to other tickets.

Ticket type. This is one of most misused fields, with many people marking tickets as defects that should not be. To address this, here’s a reminder of the ticket types and their intended uses. Your choices are: defect (bug), enhancement, feature request, and task (blessed).

• Defect (bug). Something is broken. You know how the feature is supposed to work (if you’re unsure, check the Codex or ask in the dev channel), but something has gone awry that needs to be fixed.
• Enhancement. Something is awkward or slow and could be designed or coded better without overhauling the function or screen design. Please don’t mark something as a defect (bug) if it is really an enhancement.
• Feature request. If there’s something that could be improved that would require significant restructuring of code or screen design, it should be marked as feature request rather than enhancement. Please note: this is not really the place to request features that are not currently in WordPress. Please continue to use the Ideas forum to suggest new features. The core developers will add new feature requests to Trac as they review the Ideas forum with each release cycle.
• Task (blessed). This type indicates approval from the core development team. Only core developers should use this selection. If you mark something as Task (blessed) yourself, you will have bad karma.

Bug Hunts*! If you have checked the Codex page for bug hunts lately, you’ll notice it’s been awhile since there was one. No more! Official bug hunts, sprints for finding and fixing bugs, will be brought back on a regular basis. The first one will be announced soon, possibly next week, to try and tackle the bug tickets related to widgets. (No need to wait, though, there are hundreds of open tickets in the 2.8 milestone just waiting for a kind developer to pay them some attention.)

As always, contributing developers can communicate with each other and with the core team in the #wordpress-dev IRC channel at irc.freenode.net, on the wp-hackers list, and in the ticket threads on Trac. Regular developer chats in IRC will be returning to Wednesdays at noon (Pacific time) starting next week.

[* - I used to love the bug hunt challenge in Space Cadet 3D Pinball back in the days of Windows 95]

WordPress by itself is very simple — what makes it compelling for most of its users is the wide array of plugins (and themes) available for WP. The average WordPress blog has about 5 plugins installed! Today we just passed 4,000 plugins available in our plugin directory. (Which is also embedded into everyone’s WordPress 2.7 or above.)

I declare January 28th our official “Thank a Plugin Developer” day. To celebrate take a look at the plugins you use and love, visit the author’s site, find their contact form, and drop them a note thanking them. (Or Paypal!) Look for the links in the plugin directory to “author homepage” and also to donate directly if they’ve specified a Paypal address.

Thank you to everyone who has ever written a plugin for WordPress, and here’s to the next four thousand.

Everyone knows by now that WordPress 2.7 is packed with new features. Now that it’s available (almost 600,000 downloads as I write this!), it’s time to start working on 2.8. There were dozens of things that got tabled during 2.7 due to time constraints, and there are a lot of high-rated features in the Ideas forum, so there are a lot of potential features under consideration.

Right now, the lead developers are thinking the top priorities for 2.8 will be widget management, theme browser/installer and performance upgrades. The rest of the development time will be taken up with bug tickets and additional features/enhancements from a prioritized list. To that end, we’ve posted a new survey for you to help us prioritize features for 2.8. The list pulls from the developers’ “2.7 leftovers” list as well as the most popular features from the Ideas forum. Just rank each feature and tell us your top pick (up to three). You also have the option of adding comments or additional suggestions, but this is not mandatory. For your response to count, you must rank all of the features in the list. The survey has only one page.

Note that media features are not included in this list as we will be posting a separate survey for media-specific features soon.

Cast your votes any time this week, but as always the sooner the better. This survey will close at noon on December 31, 2008 UTC.

In the new year, we will be reviving scheduled IRC developer chats, where the lead developers will discuss the week’s progress on feature development, providing opportunities for people to ask questions or make suggestions. These will be held early in the day on Wednesdays (U.S. Wednesday), and the specific time will be posted here on the development blog once it’s been finalized.

As a related aside, we spent a significant amount of time during 2.7 development sifting through Trac tickets that really shouldn’t have been there. Feature ideas and requests do not belong in Trac, they belong in the Ideas forum. Please reserve Trac for reporting bugs and things that need fixing (typos, code enhancements, etc.). If you are asking for a new UI, a new feature, or a new approach to coding something, that’s not an enhancement, it’s a new feature. New features will be entered into Trac by developers once it has been determined that the feature should be included in core. To help speed up development, moving forward we will close Trac tickets that are actually feature requests, with the comment that they should be posted in the Ideas forum instead. Please help the developers maximize their time by following this guideline.

Thanks for your help!