Bug Days | How to make Bug Days run smoothly

Inspired by Atlassian’s ShipIt Days and admiring the enthusiasm of the hackathon all-nighters at Facebook, we recently hosted our first Bug Days event at RTI.

We set up this 2-day social event to fix bugs and annoyances we always wanted to fix but didn't always have the time for. (Customers, rest assured, your issues do not fall into this category. We always prioritize critical customer issues.)

We established the following goals and guidelines:

• Improve usability
• Allow engineers to address issues which never get to the top of the urgency list.
• Provide a training opportunity for all engineers - e.g., a UI engineer can pair up with an engineer focused on the OS layer.
• Foster community and team cohesion

Atlassian posted a detailed FAQ on how to prepare and run a ShipIt Day. To make Bug Days run smoothly, we worked with our product managers to make our own list of activities for the preparation leading up to the event, the day of the event, and wrapping up after the event.

1. About 2-3 weeks before the event, we solicited bug and feature request nominations from within the engineering team, as well as from the field. Bribes were welcomed. Although the event was called Bug Days, we expanded the scope to include feature enhancements for improved usability.
2. During those weeks, we worked with team leads and product managers to triage the nominated bugs. For example, we wanted issues to be completely fixed during the two Bug Days. If an issue required a large amount of rework, or if a feature required more time to implement, it was likely to be rejected as a candidate for Bug Days.
3. We created a Jira Dashboard just for Bug Days. It would track each bug, types of bugs, different products, and so on. We ended up with a list of about 120 issues across all products. It included bugs, feature enhancements, and documentation bugs.
4. To make things interesting, we assigned Jeopardy-style Daily Doubles to specific Jira issues. These were hidden bonuses: at the end of the event, if you fixed the issue, you got a prize. Prizes were contributed by the marketing team, product managers, account teams, and other managers.
   Among the prizes: Our CEO committed to serving up coffee for a week. I have to wash someone's car by hand.
5. A week before the event, we briefed the team on how the event would unfold. Since our team is geographically dispersed, we determined start times for all locations, and arranged for food throughout the day. A few senior engineers were assigned to help resolve questions as people tackled bugs. Others stepped up to be on support during Bug Days. All meetings during Bug Days were moved to other days. We coordinated tagging the tree, checking out a specific branch and the process of validating checkins and code reviews.
6. The day before Bug Days, we set up various conference rooms with large power strips, monitors, and keyboards. Each room also had a dedicated camera-equipped laptop for video conferencing.
7. Then, Bug Days arrived! We started the event at noon on Monday in our Spanish Development Center in Granada, Spain. The East Coast (Massachusetts and Florida) joined six hours later. The team in Sunnyvale kicked off their efforts at 9am. Using Google Hangout between all the conference rooms, the SDC, and other remote locations, it felt like one large virtual bug fixing community.
8. At different times between 9pm and midnight, people called it quits for day one. The Monday bug fixes were validated overnight by our nightly Bamboo plans.
9. Day two started again in Spain at noon. By Tuesday 4pm PT, we tallied the results: over 73 Jira issues were resolved. Not everybody was done however; some of the issues were resolved in the following days. We wrapped up the event, debriefed, and went next door for a couple of beers.

Bug Days #1 went great and we had a lot of fun doing it. Everyone is ready for our next Bug Days event next quarter.

The countdown has begun.