The UFO Blog

Author Archive

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.

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

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!

The community has voted, and the votes have been tallied. The winner of Project Icon, with 35% of the votes, is Entry ID “BD,” otherwise known as Ben Dunkle. Congratulations, Ben! The runner-up was VS, otherwise known as Verena Segert, so we’ll be attaching that set to the alternate color palette that is selectable from the profile screen. As we prepare for RC1, Ben and Verena will be revising a couple of their icons so that both sets will use the same metaphors, creating the colored “on” states, and creating the larger size of each icon for use in the h2 screen headers. We are very grateful to have had the opportunity to select from so many great options, and would like to express again our appreciation for all the designers who participated in the contest. Thanks also to the more than 3700 people who completed the voting survey and took the time to weigh on on the individual icon sets.

Q.18 Which one of the sets do you think we should use as a basis for the 2.7 icons?
Icon Set	# of votes	% of votes
BD	1285	35%
VS	1080	29%
GB2	424	11%
OSD	376	10%
LS	300	8%
GB1	235	6%

The wide lead of BD and VS made it clear that voters had a clear preference for these sets.

Q.20 If you could choose a runner-up, which would you choose?
Icon Set	# of votes	% of votes
VS	916	27%
BD	647	19%
LS	522	16%
OSD	488	14%
GB2	462	14%
GB1	331	10%

Question 20 was not mandatory, so a few hundred people skipped it, but the responses we did get (3366 of them) reinforced the fact that the two most popular sets were also the most popular 2nd choices, which made the decision of the judges to go with the popular vote an easy one (take that, electoral college!).

A few of the individual icon metaphors also had a significant lead over the other choices.
Dashboard: 1333 voters (40%) chose a house as the best metaphor. We agree, so both Ben and Verena will be replacing their Dashboard icons.

Media: 2097 voters (65%) chose the combination camera + musical note icon, which was part of Ben’s set. We also really loved it, and Verena will amend her media icon to incorporate this idea.

Plugins: 1682 voters (53%) selected the outlet plug metaphor, which both Ben and Verena used in their sets.

Tools: 1581 voters (49%) liked the combination of two tools better than anything else, so Ben and Verena will try this approach.

So those are the results, and soon you’ll see the new icons coming to a 2.7 installation near you.

Need another look at the entries to remember which one you liked best? Here are some reminder images, as well as the identity of each set’s creator.

BD was Ben Dunkle, a designer, professor and artist from upstate/western New York State. In case you’ve already forgotten, Ben’s icon set is the winner of Project Icon and will become the default icon set after a few minor changes.	VS was Verena Segert, our runner-up, a designer from Germany who presented sets in both grayscale and blue. Her blue icons received more specific voter comments than the gray ones, so we’re planning the second color palette to be in shades of blue so that we can use the blue icon set.
GB was Guillaume Berry, a designer from France who submitted two sets in the same style in order to propose a couple of different metaphors. One of his sets came in third while the other came in last, but whether you only look at the higher scoring set or you combine their votes, Guillaume had the next highest percentage of votes, and many people liked the metaphors he used for various icons. In fact, given the enthusiasm of the community for Guillaume’s icons, we think a great plugin would be one that would allow the user to upload the icon set of their choice. Any volunteers?
OSD was the Open Source Design class at Parson’s in New york City, taught by Mushon Zer-Aviv and consisting of students Alexandra Zsigmond, Ed Nacional, Karen Messing, Khurram Bajwa, Leonie Leibenfrost. Teacher and students worked together to determine their metaphors and visual style.	LS was Luke Smith, a designer from Iowa who specializes in icons among his other design pursuits.

If you need to hire an icon designer any time soon, we highly recommend our Project Icon contestants, who all delivered great work in a very short timeframe. It was great to work with all of them, even for such a short assignment.

So, to sum up:

1. The winning icon sets by Ben Dunkle and Verena Segert will be incorporated into WordPress 2.7 RC1.
2. Someone should write a plugin that would allow anyone to upload a custom icon set (I bet the other contestants could be convinced to release their icon sets for such a purpose).
3. 2.7 is still trucking away, but we can always use help with patches, especially for IE6! (I know, that wasn’t in the main post, but it’s true, so hmph)

Thanks again to everyone who participated in this experiment, and we hope you enjoyed it as much as we did. And congratulations again to Ben and Verena!

Earlier in the beta period, we put out a call here on the development blog for designers in the WordPress community who might be interested in designing custom icons for the 2.7 admin interface. Over a dozen icon designers from around the world responded, so rather than choose just one, we decided to turn the icon design assignment into a contest so that more people could participate and the community could have a vote in what the new icons should look like.

Once we decided to go with a contest format instead of a single-designer gig, about half the original volunteers changed their minds. The remaining designers each submitted two icons (Posts, Links) in their proposed style. At this stage a couple of designers were thanked for their submissions but eliminated from the competition because their icons were considered too far afield from the WordPress visual style. The remaining designers were given feedback on the icons they had submitted and given about a week to complete the icon set for the menu as well as the list/excerpt icons that are shown on the Edit Posts screen. All but one of these designers finished a complete set, giving us five sets in total.

So now we need to choose a direction. For each of the icon sets, we’ll show you the set itself, the designer’s introduction, and some feedback from the lead developers. After you’ve reviewed all five, place your vote for the set you think has the visual style that is the most suitable for WordPress 2.7. This will be followed by additional votes on specific icons, so if you like the specific image used in one set but like the style of another, you can vote to change the metaphor for a given icon. You’ll also be able to leave general feedback throughout the voting process. When voting has concluded, we’ll review the comments and the votes, and will declare a winner.

Things to bear in mind when making your selections:
A week is not a long time to create 13 icons. The winning set will undergo a revision to be refined, and some icons may be substituted. We asked for all icons in grayscale for the contest. An “on” state and a larger size for screen headers will be designed by the winner. It seemed like too much work to have everyone do multiple states for so many icons.

Ready? Go and take the icon survey. Voting will remain open for 48 hours from the time of this post to allow people from all time zones a chance to participate before we close the survey and make a decision (since we’d like to include the new icons in Beta 3).

A Note Regarding the 2.7 Release Date:
As we approach Beta 3, bug tickets continue to be added to Trac, the pain of making things look good in IE6 continues to be felt, and the need to improve accessibility looms. If you love WordPress, are a decent coder, and want to contribute like these icon designers contributed, please consider contributing a patch to help with one of these efforts. Jump right in on current Trac tickets, or pop into the #wordpress-dev IRC channel to ask what to do.

There have been a lot of posts and twitter announcements by people checking out the WordPress 2.7 Beta since it was announced yesterday. What’s your favorite thing about 2.7 so far? Or if you haven’t made the leap yet, to which feature are you most looking forward? Tell us in the poll below.

What is your favorite feature in WordPress 2.7?
( polls)

If you have a extra minute or two, we’ve also put together a survey that lists all the new features and allows you to rate them, as well as give additional feedback if you’re so inclined. If you want to participate, take the 2.7 Beta Favorite Features survey.

A question I hear pretty frequently is, “Why a redesign of the admin panel so soon after 2.5?” Those who have attended WordCamps in the past few months have already heard the answer, but for the people who haven’t had that opportunity, this post is for you.

When the community response to the 2.5 admin redesign was mixed, it seemed like a good idea to do usability testing to find out which issues were based on actual interface problems vs. which complaints were just a result of not liking change. To prevent bias, a third party was contracted to conduct usability testing, Ball State University’s Center for Media Design, Insight and Research division. Try saying that three times fast with a mouth full of peanut butter. Or fitting it on a business card. To save time, we’ll just call that third party CMD, since that’s what they call themselves.

The plan that was developed involved multiple rounds of testing, as well as the creation of two prototypes, hardcore! The first phase involved a usability review of 2.5 by CMD, the results of which were discussed with lead developers. A quick prototype was created that addressed some of the lightweight issues, so that the test participants could use both 2.5 on their own blogs and the prototype on a test site. Results would be analyzed and compared, leading to a second round of suggestions. A second prototype would be developed over a week or two, which would then be tested with the same participants, and a final report delivered. But you know what they say… the best laid plans of designers and developers often go awry.

After the first round of testing, it was clear that a prototype delivering the kind of fixes that could be coded in a week or two wouldn’t make much of a difference overall. We all decided a more ambitious prototype was in order, one that would experiment with a new approach to screen real estate and attempt to address as many of the issues from 2.5 as was possible with a few extra weeks of time. A rapid design process was followed by an even more rapid development cycle. The second prototype is what you know as Crazyhorse.

The second round of testing blew everyone away. The research team had never seen such consistent results. Tasks were completed faster, participant opinions rated it higher, understanding of how interface elements worked was greater, and it wasn’t even a fully functional application. Of the test participants, every single one said they would choose the prototype over their current administrative interface, and it wasn’t even pretty (those of you who remember the original Crazyhorse will vouch for this).

A presentation on the process from start to finish was part of the schedule at WordCamp 2008 in San Francisco, and the slides are available online, but as always the slides only tell you so much without the videos, live demo and verbal narration that went with it. (Use Google and you can see audience videos of the presentation.)

Here, then, is a PDF of reasonable size that you can download and peruse at your leisure that outlines the usability testing project in some detail. I wanted to include some eye tracking videos, but the file was so huge it would have been ridiculous for anyone to download it, so I stuck with eye tracking outputs called gaze trails to illustrate the findings. I also tried to pare down the text to the more salient points, since more than 50 hours of test video really does reveal an insane amount of data. I also cut out the section about designing Crazyhorse in the interest of staying under 25 pages. Hopefully you’ll think it’s a good balance. I’ll try to put together a separate document on the design process of 2.7 in a couple of weeks that will include the early Crazyhorse material.

So, if you want to know what we learned from the usability testing this summer that caused us to create what is now 2.7, go ahead and read the report.

WordPress 2.5/Crazyhorse Usability Testing Report (PDF)

Have you seen the getting-prettier-all-the-time menus in 2.7-almost-beta? They really are. Getting prettier all the time, I mean. Once we drop in the fonts and do a little brushing up of edges and colors, the menu system is going to be smooth. The last thing we’ll need to do to is replace the icons we’ve been using as placeholders. Currently, the menus are using icons from Crystal Project, which is perfect because they’re released under LGPL (yay for open source!), but less perfect in that they don’t quite fit with the new visual style of 2.7, so we’re thinking custom icons.

I’m always meeting people at WordCamps or via email who say they wish they could give back to WordPress, but that since they aren’t PHP developers, they feel like there isn’t any opportunity for them to be a part of the open source project. Well, here’s a golden opportunity. Want to design the new WordPress icons?

The icons:
We’ll need icons for each of the main navigation sections, plus a matching pair of list/excerpt view icons for the table screens like Edit Posts. That’s a total of 13, and for the navigation icons we’ll also need a larger size for use in the screen headers. Some of the sections have natural iconography, while others may be more challenging. The sections are: Dashboard, Posts, Media, Links, Pages, Comments, Appearance, Settings, Users, Plugins, Tools.

The style:
Icons should be subtle, with a classic/designed look, nothing cartoonish. Thin lines. Maybe a little old-fashioned looking. They’ll be grayscale by default, possibly with a color version for active menu items.

The timing:
Fast, fast, fast. 2.7 is due to release on November 10. That means icons need to be ready within two weeks, give or take.

The required experience:
To be taken seriously, you’ll need to show a background in icon design. It’s a different skill than web site or application design, and given that there’s not much time before the 2.7 launch, someone with experience (and possibly existing work they can leverage) is going to be the best candidate.

Interested? Send us an email and tell us why you want to design the icons, and include a link to your portfolio. How we wind up choosing an icon designer will depend on how many people respond, but we’ll keep you posted on the process. For now, send in portfolio links by Saturday night, October 25, 2008. We’ll review them over the weekend and get in touch with people on Monday. Hopefully we can be designing by early next week.