The road to wisdom? — Well, it's plain and simple to express: Err and err and err again but less and less and less. –Piet Hein

Project Management at Mozilla

One of the most interesting aspects of my OPW internship is learning how contributions and planning are managed in Mozilla projects. So huge! So many contributors! Ahhh! Mozilla is known for giant projects like Firefox, but it also builds lots of supporting tools and websites. All projects, big and small, are managed using Bugzilla and often a mix of other tools, depending on the project team. My observations are based mostly on one project that I’ve become familiar with: One and Done. Warning: I’m going to say “Bugzilla” a lot.

Bugzilla

Bugzilla is used to describe “bugs” and track their status. A “bug” in Bugzilla in not necessarily a problem that needs to be fixed: it can be feature planned by the core project team, a suggestion from a community member, a representation of a project milestone or even a request for new office furniture for a team member. Seriously.

Ideally, all the discussion about a bug takes place publicly in its Comments section on Bugzilla so that everyone can see how the bug is evolving and anyone can join in. (Not all discussion is public: bugs that relate to a security vulnerability can only be viewed by authorized users.)

If the bug represents a new feature, people might use the Comments section to narrow down or adjust requirements, request clarification or feedback, etc.

Bugzilla is also where developers submit solutions for code review.

Bugzilla with Github

Like many other Mozilla projects, One and Done has its repository hosted on Github. Github Issues are not used at all since Bugzilla bugs fulfill their role. When a developer makes a pull request on Github, that PR should refer to a Bugzilla bug ID and it should be attached to the bug in Bugzilla with a request for review. (Example 3: Completed Tasks PR.) One can also add a brief summary of the PR in the bug comments. Detailed discussion and feedback about the code takes place in the pull request on Github, but a summary thereof is always included in Bugzilla, often by the reviewer.

One Source of Information

Since there are so many tools available to describe and communicate about project progress, it’s a common problem to have project information spread around in many different places, where it may be overlooked or become out-of-date.

In the case of One and Done, although there is a project wiki, a Github repo, a Kanban board and brief discussion over IRC and email, all the key project data is in Bugzilla or linked-to from there. As a contributor to the project, there’s really only one place I need to look for definitive information, and that’s Bugzilla. Bugzilla, Bugzilla, Bugzilla.