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.
I totally agree with you Siobhan. I’ve never been to a hack day, because I don’t feel like I belong. This summer in Vancouver with a Theme development weekend and there were folks who joined that didn’t know any code. Designers know that their skills are needed when building themes and so they felt included.
I think that renaming hack days to WordPress contribution day or something similar would be great.
I also have this weird feeling about the word hack. To me a hacker is someone who is trying to get into someone’s email/bank account and steal stuff. I think that’s just me though. 🙂
Great post, Siobhan. I was at WordCamp San Francisco, and I was both confused and a little annoyed by the communication about Hack Day before the event. I was confused who was “qualified” to go, and confused why there wasn’t an option for people that love WordPress and wanted to contribute, but weren’t developers.
I even sent an email via the WCSF contact form with my concern a few days before the event, with a request to at least make an announcement for a non-dev, non-official event somewhere so people that were in town a second day and wanted to do something to help either the WordPress project, or just each other, be able to do so. I didn’t get much of a response.
I know smaller events are hard to plan. But even then, I feel like these Hack Days can be divided up a little differently, like you said, so that there are essentially group leads to spearhead people that want to contribute, but have varying levels of expertise.
We certainly shouldn’t be putting off people that can write great docs, or take great notes, or can give design or UX input on code decisions, or can just express challenges for every day users that devs may not think of.
Hopefully this will start to happen more often. I certainly hope these dedicated members of the community are accounted for at the next WCSF, unlike this year. And may I propose we call it a “I love WordPress” day – where the requirement is to work for the benefit of the project in some way that’s not your own project or support requests. Other than that – come one, come all.
It’s a shame that WCSF didn’t take your suggestion on board. I understand that developers want to be able to work on tickets, but there’s no reason that this can’t go on alongside other things. Also, people who aren’t developers get invited to come along because they’re friends with developers, and then it’s in danger of becoming cliquey. If we want more people to get involved we should use terminology that is inclusive and create events that welcome everyone.
That’s not to say that there shouldn’t be developer-only events – the Developers WordCamp in Toronoto and the wp-hooked meetup in London demonstrate that they popular and developers find them useful. It just can be a little alienating if they’re directly following a more general WordCamp.
This is a great post. I’ve always wanted to contribute to WordPress, but I’m not a hard-core coder. I’d love to contribute documentation, specifically on the accessibility front, but have no idea where to even begin doing this. I’m looking into it seriously now though, and hope that 2013 will see increased contributions from myself.
I think you’ll see more information on how to contribute over the next few months. A good place to start is the make/wordpress blogs. There are blog for accessibility and docs. There are a number of projects going on in docs right now so definitely feel free to drop by!
Lisbon’s “day” was never meant to be a developer-only-working-on-core-tickets session. Granted, core tickets need work from all, but it is not always obvious, even for qualified developers, to get past the barrier of actually submitting a patch to core; to cross the technical barrier of is feasible for many, but dealing with the social dynamics of core’s trac isn’t always so.
That said, a few at that day did submit patches, but we’ve had, as you mention, all kinds of contributions. This was not a plan per-se, just the result of not knowing exactly what a local “hack day” would have to look like. We did it anyway, relying on everyone’s eagerness to pitch in to make it work. It did.
I suspect many other WordCamps avoid the “hack day” exactly because of all this, in which case I strongly advise them to turn it into a “contribute-to-wordpress-with-what-you-do-best day”. That way everyone can participate and feel valued for its contribution, no matter how small or how distant from core code.
Hack day where we can’t hack? 🙁
Hacking is just a part of how you can contribute.. right?