Page MenuHomePhabricator

Discussion: Redefine Wikimedia Hackathons?
Closed, ResolvedPublic

Description

Time / Location: Wikimedia Hackathon 2016, Saturday 15:00 - 16:00, Room 1.3
Etherpad Link: https://etherpad.wikimedia.org/p/WikiHack16-Redefining_Hackathons (content below in this task description)

Do we like hackathons they way they are? What can we do better? What should stay the same no mater what?

This session is intended for long term Hackathon veterans who have opinions on what works and what does not work.

Relevant links:

Etherpad content from Wikimedia Hackathon 2016 session:

Session name: Redefining Hackathons
Meeting goal: Talk about the future of hackathons, how can we improve?
Meeting style: Problem Solving, Discussion

Phabricator task link: https://phabricator.wikimedia.org/T124262
This session is about long term changes, not about feedback or complaints specific to this 2016 edition.

Topics for discussion:

  • What works?
  • What does not work?
  • Ideal hackathon size?
  • Key roles to fill? What needs more attention?
  • Should we continue to hold one big hackathon a year or would it be more beneficial to hold multiple smaller ones?
  • How can we support local events?
  • What documenting is missing?

What do we know about people's opinions on hackathons

  • We run a survey after every hackathon, but the responses are quite specific to each event. Let's think more strategically, more longer term in this session.
  • There hasn't been a survey about what people expect about hackathons in general. Maybe we should organize one.
  • Asking also about the Summit, that could be useful.
  • Qualitative surveys, like talking 20 minutes with a group of individuals.

What works

  • Having specific technical goals e.g. Community Wishlist or Wikidata tasks. Avoid "hackathon projects" that are never touched again.
  • Informal, flexible, having plenty of space for changing plans based on the demands ad hoc.
  • Scholarships to volunteers that come and find quiet rooms to work on what they already had in mind and now have plenty of time to work on.
  • Mixing junior and senior developers, so the former can get advice, and the later are happy to help directly in fresh projects happening now.
  • Showcase, a platform to present results. That brings some pressure, and some satisfaction.

What does not work

  • Why the buddy system didn't continue? Last year was basically mandatory, we really pushed it, and this make many people not comfortable, or theoretical buddies never actually got to work together. Mathcing people was also very complex.
  • Organization of projects and teams before the hackathon. People didn't find a clear way to show interest and get organized.
  • Allow people to promote their projects beforehand, provide people clear steps to sign up and get organized.
  • The information is there, but it is difficult to get an idea of all the info, and the call to actions.
  • Duplication when sending links to people; have a clear structure for the Hackathon page
  • Add <tl;dr> at top ("The 3 things you must do before coming here")?
  • Less splitting things into sub-pages.
  • Add IRC office hours, or talkpages, where newcomers can ask questions a few months beforehand.
  • Skills are not visible: who knows about what? For instance, we need a designer...
  • Programming languages are not visible, and in fact this defines a lot where a new developer will and will not be able to work.
  • Specific instructions for newcomers beforehand. Vagrant, git, phabricator, explanation of gadgets vs tools vs extensions,
  • Avoiding disruptions nearby - e.g. loud music playing during working times. Making it easy to get food at any time (not forced to get lunch within a single hour)
  • After the hackathon, how to continue the work, how to pickup work that was left half-backed. (There is a connection with Wikimania hackathon, Phabricator tasks help continuity.)

Ideal hackathon size?

What about hackathons on topics/specific areas? Little ones focussed on things like content extensions or usability or whatever?

  • Now we are aiming for about 150 in Wikimedia Hackathon, and Wikimania's is out of our control. (also Wikimania is problematic because the profiles are a lot more mixed, and more people is around just because Wikimania is next)
  • Why 150? It is probably the maximum operational size. Larger will probably break the "one dimension" of the event, and would probably break into silos. The number of local developers (newcomers) may increase, though.
  • % of newbies, it is a tricky balance. We want oureach, but too many might lower the quality of the event.
  • Focusing hackathons by tech (i.e. Lua, Tools, Python, Mobile) could also help. Or a track?

Documentation

Action items with owners

  • @Rfarrand to explore the possibility of organizing a (qualitative?) survey.
  • @Rfarrand to explore possibility to have scholarships / prizes to send great Wikimedia Hackathon developers to Wikimania Hackathon.
  • @Qgil to file a task about branding, for discussion. Possibly get chapter-hackathons to test the concept.

Event Timeline

Rfarrand created this task.Jan 21 2016, 1:26 AM
Rfarrand updated the task description. (Show Details)
Rfarrand raised the priority of this task from to Normal.
Rfarrand claimed this task.
Rfarrand added subscribers: Rfarrand, Qgil.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 21 2016, 1:26 AM
Rfarrand renamed this task from Redefine Wikimedia Hackathons to Discussion: Redefine Wikimedia Hackathons?.Mar 23 2016, 7:51 PM
Rfarrand updated the task description. (Show Details)
Rfarrand set Security to None.
Rfarrand updated the task description. (Show Details)Mar 23 2016, 7:57 PM

Note: This comment pretty much ignores the task description but provides some further food for thoughts.

If I managed to summarize correctly, https://modelviewculture.com/pieces/software-in-person proposes

  • meeting across disciplines (designers, engineers, documentors) to get to know each other and understand approaches for collaboration,
  • getting everyone set up with tools via hands-on workshops,
  • publicly walking through code to let engineers explain certain patterns and which decisions were made why,
  • working on existing project proposals (and following up on them before and after the event) more than on crazy new fun ideas (which is T119703),
  • having a showcase not on the very last day (so interested people could still join efforts?).
Rfarrand updated the task description. (Show Details)Apr 3 2016, 11:07 AM
Qgil added a comment.Jul 5 2016, 8:58 PM

What is missing to resolve this task?

Aklapper updated the task description. (Show Details)Oct 5 2016, 12:44 PM

What is missing to resolve this task?

Quoting the action items from the Etherpad:

  • @Rfarrand to explore the possibility of organizing a (qualitative?) survey.

@Rfarrand to either create a task or decline the idea.

  • @Rfarrand to explore possibility to have scholarships / prizes to send great Wikimedia Hackathon developers to Wikimania Hackathon.

Covered in T132109.

  • @Qgil to file a task about branding, for discussion. Possibly get chapter-hackathons to test the concept.

@Qgil: Has that happened? If not, do you still plan to do that?

And I'd add:

Qgil added a comment.Oct 5 2016, 8:13 PM

Quoting the action items from the Etherpad:

  • @Rfarrand to explore the possibility of organizing a (qualitative?) survey. @Rfarrand to either create a task or decline the idea.

This was T132108

  • @Rfarrand to explore possibility to have scholarships / prizes to send great Wikimedia Hackathon developers to Wikimania Hackathon. Covered in T132109.
  • @Qgil to file a task about branding, for discussion. Possibly get chapter-hackathons to test the concept. @Qgil: Has that happened? If not, do you still plan to do that?

There was discussion and agreement in Wikimania. The result can be seen in the logo at https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2017. Done.

And I'd add:

Aklapper added a comment.EditedOct 6 2016, 7:13 AM

Yay, momentum. Thanks! :) Taking a closer look at the list above and what might not be covered sufficiently yet:

  • Allow people to promote their projects beforehand
  • After the hackathon, how to continue the work, how to pickup work that was left half-backed. (There is a connection with Wikimania hackathon, Phabricator tasks help continuity.)

I'm still not sure if we have a sufficient plan (or dedicated task?) to cover these two bullet points. We only have "Save at least 20 minutes for participants to introduce their projects" right at the Opening session. Which is (too?) late? But see "Skills are not visible" below in this comment, that looks very related.

  • Add IRC office hours, or talkpages, where newcomers can ask questions a few months beforehand.

Would the Discussion page of mw:Talk:Wikimedia_Hackathon_YYYY be sufficient, and adding a section "Any questions? Ask on the talk page!" to mw:Wikimedia_Hackathon_YYYY ? List this 'Make sure to have such a section' ToDo item under "Make an event wiki page, list it on Events"?

  • Skills are not visible: who knows about what? For instance, we need a designer...

We do put "Interest Areas" on Name Badges and we have mw:Wikimedia_Hackathon_YYYY/Attendees. Should that page simply be a table to encourage adding both user names and areas of interest && plans what to work on? (That could also cover "Allow people to promote their projects beforehand" above a little bit.) I'd prefer to crowdsource instead of throwing received registration data over the wall. List this 'Create an Attendees subpage with the following columns' ToDo item under "Make an event wiki page, list it on Events"?

  • Programming languages are not visible, and in fact this defines a lot where a new developer will and will not be able to work.

Is that T136866? Or does this refer to attendees? Or both? If attendees, again, add a table column to the /Attendees subpage?

  • Specific instructions for newcomers beforehand. Vagrant, git, phabricator, explanation of gadgets vs tools vs extensions,

Sounds a lot like adding a sentence like "Read mw:How to become a MediaWiki hacker if you are new to Wikimedia code" to "Draft and send a welcome email for participants" ?

  • Avoiding disruptions nearby - e.g. loud music playing during working times. Making it easy to get food at any time (not forced to get lunch within a single hour)

Added.

Qgil added a comment.Oct 6 2016, 4:36 PM

Yay, momentum. Thanks! :) Taking a closer look at the list above and what might not be covered sufficiently yet:

  • Allow people to promote their projects beforehand

All the prior work could be discussed in the context of T120092: Hackathons: Help people connect and start collaborating in advance of Hackathons

  • After the hackathon, how to continue the work, how to pickup work that was left half-backed. (There is a connection with Wikimania hackathon, Phabricator tasks help continuity.)

If the "pre" part works better, probably the "post" part will improve almost magically. It is (almost) all about the inertia of the hackathon projects and the health of the personal connections established around them.

When projects rely only on the inertia and personal connection acquired during three days of hackathons, that is a fragile balance. When projects arrive to the hackathon already with a strong inertia and a group of people that has been planning together for a while, that is more difficult to stop.

I knew the task exists. And I failed finding it. :( Thanks.

I'll boldly CC @Claudia.Garad here because I'd love to get feedback if stuff in T124262#2696003 sounds feasible.

Allow people to promote their projects beforehand

So what we are doing right now for this: https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2016/ParticipantInfo
The first column is a question in registration that people can opt into. The rest is filled in later and participants are asked multiple times to go there and fill in the rest. It does not work very well, but works a little bit.

One thing I was thinking of for this year was to send a VERY SIMPLE survey out to participants like 2 weeks in advance of the hackathon asking them for more information on their plans, projects, skills to offer etc. and then sending out a pre-hackathon participants news letter with the projects summarized and linked in an email. While also posting the info on the event wiki. It can also potentially ask people for help researching or setting up things in advance of the hackathon - these things can be front and center in the newsletter.

Otherwise, I was also thinking of doing a very informal IRC hour where people can join and talk about their projects, ask for volunteers, suggestions, etc. I can be there along with @srishakatux and maybe @Aklapper to help facilitate. If a bunch of people come, great! If not, no real harm done.

After the hackathon, how to continue the work, how to pickup work that was left half-backed. (There is a connection with Wikimania hackathon, Phabricator tasks help continuity.)

I have fewer ideas for this one, however perhaps Developer Relations could choose one unfinished project that we want to support and then find ways to support in including things like scheduling check-ins, buying "working lunches" for people involve (even if they are remotely distributed) or even possibly trying to get participants physically in the same place if reasonable.

It is also looking like getting a very small number of spots for people at the Hackathon to Wikimania will be possible. This is not finalized yet.

@Claudia.Garad & I can chat more about the registration - but I think that we can just include a section in the registration form that will all be published on the public wiki in advance and it can include more sections including "programing languages" and "skill sets" as well as what we already ask.

So what we are doing right now for this: https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2016/ParticipantInfo
The first column is a question in registration that people can opt into. The rest is filled in later and participants are asked multiple times to go there and fill in the rest. It does not work very well, but works a little bit.

Interesting, thanks! (Especially as it allows me to realize why I often don't fill that out either.) Could we:

  • rephrase "Contact information (add the best way to contact you at the event)" to "Contact information (add the best way to contact you)" so this also covers contact before the event? As my reply regarding "at the event" is always "Catch me if you can"? :)
  • remove "Additional Information / Where can you be found at the event?"? I don't consider it useful enough. People move around. And there aren't always dedicated rooms already known and announced when filling it out, except for "Hackerspace" or such.
  • maybe rephrase "Link to Phabricator tasks / projects that you will be working on at the Hackathon." to "Tasks or projects you plan to work on; areas that interest you; programming languages that you know"?

@Aklapper
Yes, all good suggestions - my main strategy change will be to collect more information during registration. We will ask all registering participants to provide this information instead of allowing a few to opt in as an after thought.

The "Where can you be found at the event" was an experiment that did not end up working out. We added it just before the event started and during the opening of the event asked people to update it when they knew where they could be found. I learned a few things - but the most important being that only a very very small percentage of participants will update anything after the event starts.

Based on my understanding from this thread, and a few hackathon related pages, adding a few more points to your thoughts @Rfarrand and @Aklapper:

Grouping people before the event is a very good idea. We could craft the survey asking participants about the hard and soft skills they possess, gender and ethnic group they belong to, the level of expertise they carry in a particular area, project themes they are interested in working on, or any new project idea they would like to propose, etc.

To let people communicate with each other before, during and after the event and for us to be able to stay connected with them throughout, we could maybe add them all to an email thread, to a slack channel (only if its okay to go with a proprietary tool) or matrix (http://matrix.org). Slack or matrix might be an interesting way to promote conversations between project teams before the event and for us to be able to share any resources, announcements, etc.

Qgil added a comment.Oct 27 2016, 1:24 PM

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

Not a perfect fit I would say, but if there is high demand I can organize a last min unconference session.

I promise that this (and other hackathon related issues) will get more attention as soon as the developer summit has ended. For the next two months there is going to be little time to dedicate to other projects and planning.

Rfarrand lowered the priority of this task from Normal to Low.Jan 6 2017, 10:20 PM

moving all tasks unrelated to dev summit to low, will readjust after summit.

Qgil added a comment.Mar 14 2017, 2:28 PM

Are any of these ideas being planned for the Wikimedia Hackathon in Vienna?

Rfarrand closed this task as Resolved.Mar 16 2017, 10:15 PM

I am closing this topic but would like to continue the discussion in Vienna.

  • Since we created this task and talked in Vienna we have redefined the Hackathon branding to be consistent every year.
  • We have connected our technical events to each-other Pre-hackathon participants are sponsored to go to Vienna. Participants who do well in Vienna are sponsored to go to Wikimania Hackathon, and as long as this project is funded in the 2017-2018 budget we will be follow up Wikimania with much smaller more focused hackathons too.

A main focus for Technical Collaboration in 2017-and-beyond is to really focus on RETENTION and onboarding technical newcomers. Basically all of our main actions and new initiatives should be in support support these areas.

Please add a link here to any first-drafts of documentation on the retention area @Qgil
Here are some more relevant tasks & pages:
https://phabricator.wikimedia.org/T148598
https://phabricator.wikimedia.org/T149564

One thing that we were not able to accomplish in 2016/2017 is any progress or first steps on a qualitative survey for hackathon participants.

A few additional things we are working on are:
Skill sharing programs https://phabricator.wikimedia.org/T160707
Mentoring programs (WMAT managing)
Making the Wikimania Hackathon Showcase more friendly to non-technical groups https://phabricator.wikimedia.org/T160708
Three steps to getting started: https://phabricator.wikimedia.org/T160706

There are still a lot of questions, but we have come a very long way. Please follow the Developer Relations team goals and the tasks linked above for ongoing work in this area.
I will probably hold another session in Vienna to follow up on the original one. The point being to brainstorm with other participants on retention and onboarding. https://phabricator.wikimedia.org/T160710