Webdesign Kapeljosie – Kapeljosie Webdesign

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 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]