Prep Discussion Around Future Hackathons
Observed Problem
Hackathons are great! But they often require team members to spend more, unplanned, time reviewing UX MRs. This is compounded by the fact that some teams are more heavily affected by the MRs that are created as their groups have higher visibility or usage than others. This may lead some of those less heavily affected teams to work as usual by picking up MRs as they have time as opposed to making the extra time to help pick up the surplus during Hackathons.
This is again compounded when a hackathon falls within a holiday-heavy month such as December.
Additional Problems
Many of these MRs are also written incorrectly, lacking descriptions or not meeting code review guidelines. This makes it difficult to review an issue as they now require additional digging and research to more completely understand the work being done.
- Suggestion: Have the MR reviewer follow the guidelines, ping the author for additional information/clarification. If the author does not respond, ping the EM and PM to take over.
Possible Solutions
- Prior to a hackathon kicking off be sure to include a warning about team member capacity during Milestone planning.
- I'd like to discuss everyone's thoughts about what is a reasonable amount of time (e.g. velocity weights) a team member should expect to set aside?
- Teams with heavy MRs to be reviewed could triage issues that they can't get to, marking the line item in the #ux-community-contributions channel and ping the @ gitlab-com/gitlab-ux/designers group in the issue
- Look into how dev teams manage this today as they tend to have many more MRs to be reviewed than we do