Hi all wikitech-ers,
I wanted to summarize a few lessons learned from the Wikimania Hackathon
and make myself available to discuss any of these issues at greater length
on the list.
Also, if you (as an attendee) have other thoughts you want to share about
the Hackathon, feel quite free to email the list, just myself, or just
Sumana if for any reason you want your identity or your feedback to be
more private.
(Note: This is probably going to get long! If you just want the "lessons",
look at just the header names.)
= Preface =
My major interest in the Hackathon was to encourage newcomers to step up
their abilities, in terms of editing the encyclopedia, programming bots,
or whatever exciting tech-related thing they want to be better at.
= Thanks =
Major thanks for the Hackathon go to:
* Sumana Harihareswara for inviting OpenHatch to lead the newcomer
portion of the Hackathon;
* Greg Varnum, for being a hugely awesome local co-organizer;
* James Hare, for managing the local logistics and generally helping make
thigns go smoothly behind the scenes;
* Katie Filbert, for helping tremendously with pre-event planning; and
* Mike Linksvayer, who was my other OpenHatch co-organizer, for taking
care of lots of essential tasks like emailing local logistics folks and
signing attendees in.
= Thoughts =
== The combination of newcomers and experienced people seemed to work ==
We got two different notes in the exit survey about this -- one from a
person who said they were happy working in the big open main room and
didn't feel distracted by noise, and from another person who said they
went off because they found the main room too noisy.
I did really like being able to send people to nearby experienced folks to
have a chat. This was especially helpful as I walked around and asked
people what they wanted help on, or what they wanted to work on.
I did notice some experienced people, by the second day, had wandered off
to quieter rooms than the big main room. I'm glad we had those rooms. (I'd
love to hear from those people if they felt "pushed out", or if they
instead felt happy that the quieter rooms were available.)
== We made a good impression by just running the event ==
One prospective attendee who, sadly, couldn't make it, indicated to me
that just by reading the survey we sent to prospective attendees, and
skimming the list of tasks, it was something that they'd be interested in
attending, and that it was great that such an event was going on. In
particular, they suggested it felt more like a "play-with-stuff-a-thon"
rather than a "hack-a-thon", and described that as making them feel
welcome.
If anything, we should have capitalized on this more. I heard from other
prospective attendees that they didn't know the Hackathon was intended to
be newcomer-friendly this year.
Personally, I think the term "Hackathon" gives an exclusionary vibe, and
that a newcomer-oriented event should have a different name. For example,
Boston Ruby recently started using "project night" at our (OpenHatch's)
suggestion and it seems to have gone well for them:
https://openhatch.org/blog/2012/the-steps-boston-ruby-is-taking-to-become-f…
== Many people did cool things for the first time ==
I heard from at least two people who made their first edit to Wikipedia
during the Hackathon! I saw one person write a bot for what I believe was
the first time, as well get a labs account and work on moving that bot
there. In the exit survey, one attendee wrote, "I learned a lot about
batch upload." Another wrote about making their first commits with Git and
Gerrit.
I think this is the most exciting thing about a newcomer-friendly
Hackathon -- it creates an environment where people can step up to the
next level, and hopefully stay at that level through self-driven follow-up
practice. This is how community growth happens.
That reminds me: Two people did indicate on the exit survey they'd be
interested in follow-up mentorship. I'm going to see how we can best
support them; I might just send them a periodic email to see what they're
up to and see how I can personally help or direct them to help.
== Wi-fi was a serious obstacle ==
I personally had a lot of trouble with my laptop failing to stay on the
wifi. I would estimate at least 10-25% of attendees had a serious problem
with this.
It's especially tough because on one hand, the Hackathon is a very
wifi-dependent event. On the other hand, the Hackathon is a pre-Wikimania
event, which means that unless there's serious pre-pre-event testing of
the wifi, Hackathon attendees are the ones that will run into any problems
that occur.
(For those interested in minutiae, it seemed that roaming between access
points triggered the problem. The problem as users experienced it was that
randomly they would suddenly see 100% packet loss with no obvious way to
fix it.)
A sample of things we saw from this:
* At least one person reports in the exit survey that it was impossible to
get work done with the wifi the way it was.
* Mike and I couldn't sign people in using the wiki because our own wifi
had failed, so we used a spreadsheet local to his computer. This meant
that it was harder to use the wiki to locate like-minded people.
One organizer attempted to set up a separate wifi network, which was
operational toward the end of the event. In the future, we need more
testing of this, and more of a plan for what to do if it fails.
== Logistics concerns ==
The room that we had agreed we would use turned out not to have power
strips lining the bottom of every table, so we switched rooms and had to
update signs across the event.
Some exit survey respondents indicated they wanted the event to start
later in the morning, and that they wanted the room to not close at 6pm.
I received more than a few emails from people who were, according to the
wikimania2012 registration system, signed up, but who replied to me
indicating that they couldn't in fact attend due to not receiving a visa
as needed. It would have been nice if those people had not been in the
registration system anymore marked as attendees.
I also sent out at least one email to the wrong address; the problem was
that the user who did the registration isn't necessarily the person who's
being registered. I think that in this case, one person in a company was
responsible for registering another person. We could fix this by making
personal email address a field that you enter at registration time (though
I do realize data will basically never be entirely perfect).
(Similarly, the script I was given for extracting information from the
registration system ended up suddenly failing, which slowed down the
second pre-event email.)
== Exit survey suggests people overall liked the event ==
Of those people, all of them indicate they're either "likely" or "very
likely" to recommend a hackathon organized by OpenHatch to a friend, so
generally speaking people enjoyed themselves.
== Tutorials can use TAs ==
On the second day, I found volunteeres to be "TAs" for the tutorials.
Their job was to wander around and help people with environment problems
or people just having trouble following along because e.g. their web
browser was different than the one being used by the presenter.
Another difficulty I found was that sometimes a tutorial speaker wasn't
loud enough to be audible in the back of the room.
This is above the tasks I had labeled as needed for a "Talkmeister":
http://wikimania2012.wikimedia.org/wiki/Hackathon/Volunteers#Talkmeister
Also, people who are having problem following along during a tutorial
don't always speak up. I'm glad we added the TAs, although I think further
work is required to find out how to non-intrusively convince people that
asking questions is okay. The best way I've seen is to have a very small
group, no bigger than 10, preferably about six people. I almost wonder if
we'd be better-served to use pre-recorded video tutorials with a lot of
TAs available, rather than live lecturers. Then we could easily have small
group rooms, and could pause the video.
== Next time, I'll get firmer commitments from helpers ==
One thing I did was walk around the main room, asking if people needed
anything. I did find some people willing to help out with this, but didn't
have a good sense of when they could help. Next time, I'll do something
like create an hourly sign-up sheet for this.
We did receive feedback at the end of the first day that at least some
people were very happy with the helpers. One person indicated he wished
there had been even more help. While I do think that everyone just about
got the help they needed, it would have been nice to have had a more clear
list of who's helping, partly to ensure we have more capacity, and partly
for me to know when people are planning to help, and partly to encourage
mentors to sign up for brief time slots and know they've helped the event.
== Favorites ==
People listed a wide variety of favorite activities, with all these being
mentioned more than once in the exit survey:
* Tutorials
* Talking to people
* Coding/hacking
The laptop setup process showed up once, too, as did break-out rooms.
Sadly for me, the list of "Tasks" I made wasn't a favorite for anyone who
filled out the exit survey. (Surprisingly and pleasingly, the laptop setup
was!)
== Diversity ==
I would estimate about 10-20% of our newcomer-oriented attendees were
women.
One difficulty wasa that we experienced a lot of competition for attendees
with AdaCamp DC, which took place on the same days and times. (I heard
from more than a few attendees and prospective attendees that this was a
conflict.)
(If you're not familiar with the event: "AdaCamp is a Ada Initiative event
focused on increasing women’s participation in open technology and
culture" <http://dc.adacamp.org/about-adacamp-dc/>)
Given that conflict, though, I think we did reasonably well.
In terms of other diversity, one attendee remarked to me that they were
quite impressed at the diversity of ages in attendance. I was personally
quite impressed by the diversity of experience levels in attendance.
I think we accommodate all that reasonably well.
== Exit survey: Qualtrics, etc. ==
The exit survey we ran received only 11 responses. (Our entrance survey
received over 100, but I sent it to about 400 people. The exit survey was
sent to about 45, so a 25% response rate is somewhat consistent. We had
about 65 people sign in on our spreadsheet, and about 45 of those people
gave us email addresses.)
I used Qualtrics to run the exit survey, since it complies with
Wikimedia's guidelines on data privacy/storage and relationships with
vendors.
I ran into an issue with Qualtrics where the sample email that it sent me
to preview what the form would look like wasn't an accurate simulation --
in particular, it didn't pre-fill the email address in the form in the
same way as the real email did.
Anyway, it took too long to get this sent out, partly due to time spent
learning Qualtrics that I didn't expect to be spending, partly due to my
own conference travel post-Wikimania. Given the wifi, we could have just
created a paper exit survey for people to fill out, or otherwise generally
been faster at this if we had prep'd the exit survey questions
before-hand. We can aim to do that for future events.
== Other thoughts ==
* One exit survey respondent wanted it to be easier to find people
interested in using MediaWiki and related software for non-Wikimedia
tasks, to chat with and work on tasks with.
* I treated laptop setup as a good thing for all attendees to go through
first, because it was a prerequisite for some of the tasks, but by no
means all of them. In hindsight, I would prefer to indicate on each "Task"
what setup steps are required. The people that ended up just mostly
editing Wikipedia didn't need to do them. (The other side of the spectrum
is that it was good for many people to go through them, to enable them to
do tasks that they might not have thought they could do!)
= Conclusion =
That's "it". If you read this far, thank you!
Discuss, if you like! I'm here to chat (although might take a day to see
all responses, if any, and respond in bulk).
-- Asheesh.