Jane Wells

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.

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.

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]