Proposal - Internal (Engineering) Hackathon
Proposal - Internal (Engineering) Hackathon
The discussion that led to this proposal came from the Software Engineering at Google Book Club. The topic was Developer Happiness and I mentioned that in my past experience Hackathons have been a great source for developer happiness. There are many ways that Hackathons can be implemented. This proposal is shaped by my experiences with successful and unsuccessful hackathons.
Different from GitLab Hackathon
GitLab regularly holds a hackathon that is a virtual event open to anyone who is interested in contributing code, documentation, translations, UX designs and more to GitLab. Typically this includes a list of suggested hacks. This internal Engineering hackathon proposal should not be confused with the larger GitLab Hackathon.
Purpose
Define a purpose for the Hackathon. Hackathons can range from free rein (do anything) to a very specific focus. For our purposes, I would propose that we keep the Hackathon product related but give the participants freedom to choose their area of improvement. Ensure that the goal of the Hackathon project, in some way, improves GitLab. I have participated in Hackathons where developers were given free rein to work on whatever they wanted, and typically the most successful outcomes of these events were still related to the product.
Ideas for themes:
- If you have a magic wand, what’s the one thing you would fix (tooling aspect)
- Prototype feature X with a new language
- Efficiency improvements
- GitLab Values related tools
- Example - Andreas built a plugin to his status bar to track MRs over the last 30 days.
- Chrome Extension to track your MTTM rate/MR Rate/Oldest MR needing a review
Project Pitch
For those interested in participating, they can submit a project pitch. Create an issue related to the Hackathon Epic with a summary of the project they would like to complete for the Hackathon. This should include an overview, goals and success criteria. The pitch should be enough to get interested parties excited about the goal, but flexible enough to change as the participation starts. You can create more than one pitch idea, but likely you will only have time during the hackathon to participate in one.
- Create an issue
- Assign to yourself
- Add the ~"hackaton pitch" label
- Link it to the Hackathon epic
Participation
This is for the Engineering department, but we are open to others participating within GitLab if they have approval from their managers. This is also optional! If individuals would rather not participate in this hackathon, no worries. Hopefully this will be a smashing success and we can have many more in the future.
As mentioned in the Project Pitch section, there will be those who have ideas they want to "hack" on, and there will be those who are interested in joining. If you don't have an idea to pitch, you can still participate in the Hackathon by indicating interest in one of the pitched ideas.
To participate in a hack pitched by someone else, simply indicate thumbs up on the pitch. Participants can add a thumbs up to more than one pitch to indicate interest. However, they will likely only have time to participate in one hack during the hackathon.
Logistics
Typically teams of up to 5 work best, but this is just a guideline.
Close to the Hackathon kick off, the coordinator(s) will ensure that for each project has enough participants. If no participants, the pitch will be closed.
- Create a slack channel for the hackathon (name tbd)
- Ask hack teams to update hack issues regularly so interested observers can follow along
Timeline
To give us enough time, I would recommend near the end of the year. Perhaps some weekend in either late November or early December.
- Pitch - 2 weeks
- Select Teams. This will be largely self-selecting but may require some level of coordination
- Hackathon Duration
- Wednesday start
- Friday soft deadline. Some developers/teams like to continue to hack over the weekend, but this is totally optional
- Monday presentations (async recordings?)
- 5 minute cap on presentations
- Following week - vote on winner(s)
- This should happen in the middle of a milestone so as not to interfere with last minute deliverables, timelines, etc.
- Wednesday start
Outcomes
A successful hack could
- Immediately improve the product in some way
- Lead to ideas for future improvements
- Validate a viable technology or language
- Invalidate assumptions - proving that something will not work can still be a successful outcome
Questions
- Do we make it a competition?
- If so, who judges?
- Participants
- Non-participants
- Vote by thumbs up on issue and linked presentation
- If so, who judges?
TODO
There are more details to flesh out
- Moderators
- Coordination
- Approval of hackathon
- Feedback loop