It’s become pretty standard for WordCamps to have a hack day, or a developer day, following a day or two of conference activity. The most notable of these is the Developer Hack Day that follows WordCamp San Francisco. The idea is that WordPress people get together to work on WordPress core – this could be on tickets, bugs, or developing features. Developers hang out with their laptops, drink coffee, eat, and hack.
As a non-developer, I’ve attended a few hack days. And developers are usually pleased to have me along, doing my documentation thing. However, this isn’t always the case. Here’s one conversation I’ve had:
Me: Awesome day! Will you be going to the hack day tomorrow?
Developer: Sure. What are you planning to do? Doing some sightseeing?
Me: I’ll be at the hack day too.
Developer: Really? Why?
Me: I’m going to work on some documentation with some developers.
Developer: Huh?
Me: I’ve got some guys to help me out.
Developer looks confused, then laughs awkwardly.
Me: What?
Developer: I just think it’s weird, you going to a hack day. It’s not like you can actually hack.
Me: 🙁
What’s the Problem?
WordPress is a big community with lots of people who don’t consider themselves to be developers. Or else they do consider themselves to be developers but don’t contribute to WordPress with code – they help in the support forums, translate WordPress, write documentation, or organise meetups and WordCamps. This means that the terminology “hack day” or “developer day” implicitly excludes them.
While the name and the format excludes non-developers, the people who attend normally don’t do any excluding. The 2012 WordCamp San Francisco Developer Hack Day website says:
This is not a social event, user hangout, or for people who lack a working WordPress core development environment. If you come, make sure you’re ready to be put to work on WordPress tickets—not your own themes, plugins, or websites.
I wasn’t there myself, but I followed what was going on, and the above statement wasn’t borne out. There were people at the hack day who were working on the Core Contributor Handbook – a number of whom weren’t developers, didn’t have core development environments, and weren’t working on tickets. If there are activities beyond hacking or development work, why do we retain the name “hack day”? Or if we must retain the “hack day” terminology, how do we change the perception of what “hack” means in the WordPress context?
Moving Beyond Hack Days
Much of the focus at the WordPress community summit and afterwards has been on how to increase contributors across all of the groups, and how to acknowledge non-core contributors. By focusing solely on developers following WordCamps, the WordPress community is missing a trick. Already, hundreds of WordPress enthusiasts are gathered together in one place, and this is the perfect time to inspire them to get involved.
At the hack day at WordCamp Lisbon, this happened in germinal form. While the day was officially a hack day, I, and other non-developers, were encouraged to come along. In one room, the hardcore developers got together and worked on tickets. There was a presentation by Scribu about how to use Subversion to contribute to core. Sat at a desk in another room, I worked on some documentation with some developers (this is always a great opportunity for me to ply people with questions). Elsewhere, developers and polyglots talked about how to improve translation processes. There were all sorts of disparate groups, working together and advising each other on making both WordPress itself and the wider eco-system better.
A Contributing to WordPress Day?
Rather than having a hack day, why not shift the focus onto a Contributing to WordPress day? Or, if that’s a little wordy, a “pitching in” day, or “participate” day, or some other name? Developers can do their development thing, and people who aren’t developers won’t feel like they’re intruding. There could be short presentations and workshops around contributing to WordPress in the many different areas that have been identified through the make/wordpress blogs. The aim would be two fold:
- Encourage new people to contribute to WordPress
- Work on tasks, features, and sprints
If representatives of different groups are already planning to be at the WordCamp, then they can help newcomers to get involved, and teams who are there could work on projects. Some examples of things that could happen:
- the Polyglots group could work on improvements to GlotPress, or on the mythical multilingual plugin.
- the support team could work on support tickets, or help other people to get involved with support.
- A seasoned meetup organiser could give a “lessons learned” presentation to help new organisers.
- the docs team could work on targeted documentation sprints.
- a theme review sprint to help reduce the theme review queue.
This would not replace the developer activity, but run alongside it, and be more representative of what the WordPress community is. There is so much potential in what the hack day could be, and it would be tremendous to see WordCamp organisers really make the most of it. There are movements in that direction, but there hasn’t been a whole lot of discussion of what a hack day is, or what it should be. It would be great to see this happen. As the WordPress Community Summit showed, we should be open to new things, different formats, and driving participation.