How We Learned To Stop Worrying And Love (Or At Least Live With) GitHub

*
Accepted Session
Short Form
Beginner
Scheduled: Tuesday, June 23, 2015 from 1:30 – 2:15pm in B202/203

Excerpt

In the past few years, GitHub has become the most widely used platform for managing open source projects, thanks to the ease it provides for submitting and accepting pull requests. However, GitHub's issue tracker is not as full featured as more venerable bug trackers such as Bugzilla, and it is not as easy to use for organizations which have a large number of casual contributors. Come hear how one organization coped with the sudden loss of their Bugzilla database by restructuring their tracking workflow to use GitHub's built-in issue management features, as well as implementing API hooks to provide missing functionality.

Description

When Dreamwidth made its public debut in 2009, our code base was housed in a self-hosted Mercurial repository, and we used Bugzilla to track issues and feature requests. In 2012, we switched over to using GitHub for our code repository, but continued to use Bugzilla instead of GitHub’s issue tracker. There were a few reasons we were reluctant to switch:

  • We needed to be open to drop-in contributors. Most of our submissions come from Dreamwidth users who are making their first open source contributions. GitHub is geared more toward full-time contributors who work on multiple projects.
  • Bugzilla provided greater flexibility. It was relatively straightforward to customize our installation with the various fields, tags, and labels that worked best for our workflow and made searching for related items easier.
  • Some of our open issues needed to be kept private for security reasons, and only made visible to a small group of trusted developers. Bugzilla made that as easy as selecting a checkbox.

But on one fateful day in early 2014, disaster struck: the virtual server that housed our Bugzilla database was deleted, with no backups. Since we were being forced to start over from scratch with our issue tracker, and because our code was already on GitHub, it made sense to move the rest of our workflow onto GitHub as well.

The major problem we had out of the gate with GitHub’s issue tracker was with permissions. We wanted our users to be able to categorize and assign themselves to open issues without granting them commit access. To solve this problem, we developed an automated monitoring system that would take actions based on the content of comments.

During the course of our talk, we will cover the basics of the system we have developed. We believe it will provide a helpful example for other open source projects, especially any projects that might have started with only one or two active contributors and now have a larger team to manage. We’ll also talk about how we addressed the workflow issues that made us reluctant to quit using Bugzilla in the first place.

Tags

github, bug tracking, automation, project management

Speaking experience

Athena presented a talk titled "User ­Created Content: Maintaining accessibility and usability" at LCA 2014. This will be Jen's first conference presentation.

Speakers

  • Jen Griffin

    Dreamwidth Studios

    Biography

    Jen Griffin has been contributing to the Dreamwidth platform since 2009. Perl is her native language. She has a bachelor’s degree from MIT, but not in any of the majors you would expect.

    Sessions

  • Athena Yao

    Dreamwidth Studios

    Biography

    Athena Yao has been volunteering for Dreamwidth since 2009. She strongly believes in the importance of accessibility and enjoys the challenge of tweaking something until it’s just so.

    Sessions