Webmaker/Code/Dev/Bugs

All the work we do is tracked in Bugzilla, and knowing how to find exiting bugs and how to file new bugs is important.

Why Bugzilla?

This question comes up sometimes, and it's worth understanding our reasons for choosing Bugzilla over Github Issues or some other tool--we have gone through a long process of discussing and exploring other options, and Bugzilla is what works best for our use case.

Webmaker isn't developed as a single code-base. This is partly due to historic reasons (i.e., Webmaker was assembled out of different, existing projects) and partly due to our deployment needs (i.e., needing to be able to scale parts of Webmaker differently in production). Webmaker is also larger than the sum of its code, and encompasses a large teaching, mentoring, and event-based community, all of which is tied into the development of the tools and apps.

As a result of the highly distributed yet interconnected nature of the Webmaker code, taking a per-repository view of of the issues/bugs has proven difficult. First, a bug might touch multiple parts of the product, and need to be spread across many repositories--it's not uncommon for a single bug to touch 5 or 6 different repositories. Second, often a bug that appears to belong to a tool like Thimble actually needs to get filed and fixed in a repository that isn't named Thimble at all, and users (and many developers not familiar with the code) can't find their way through all the Webmaker repositories.

We have taken a philosophy that favours users and bug-fillers over developers, and one which tries to provide a wide net for collecting feedback. People filing Webmaker bugs, unless they are on the development team, typically don't know our code or where bugs belong. If a bug gets filed in Github Issues, it's not possible to move it to another repository. In Bugzilla this is trivial, and it means that we can triage bug reports, CC the right people, and get our work done faster across all of Webmaker. We also favour an approach that allows us to lump bugs about code, content, and community activities into a single bucket, since Webmaker is more than just HTML, CSS, and JavaScript.

Another advantage to using the Mozilla's Bugzilla has been the opportunity to interface with other areas of Mozilla. A good example is the Security Team, who routinely helps us with security-critical bugs. In Bugzilla one can flag these such that they aren't open to the public, and therefore don't document exploits. This isn't (currently) possible in Github.

When it comes to issue trackers, there is no silver bullet, and it's impossible to please everyone. By using both Github and Bugzilla, the former for pull requests and code review, and the latter for global projecct issue tracking, we think we've struck the right balance.

Using Bugzilla

If you haven't used Bugzilla before, you need to create an account. A good first guide to Bugzilla for Webmaker users is available here: http://blog.webmaker.org/bugzilla. You should also watch Bugzilla for Humans, and read this post. There are many good resources on learning Bugzilla.

Bugzilla is organized into Products, which in turn have Components. All Webmaker bugs live under the Webmaker product, and in one of its components (see the complete list and description of each). Developers often watch particular components, which means an email will be sent for all bugs filed or updated in that component.

New bugs can be filed here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Webmaker. There are many bugs across all Webmaker components. You can see all open bugs for webmaker.org, Popcorn Maker, Thimble, X-Ray Goggles, Make API, etc. or you can see all open Webmaker bugs. Here are NEW (i.e., bugs not yet assigned to anyone) that need someone to look into:

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Good first bugs

These are bugs picked for new contributors

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);