Bugzilla workflow

Note: If you do any action to a bug, you might notice that you've just emailed a bunch of people. Don't worry. These people have opted in to receiving so many emails.

Here are the process steps for dealing with Bugzilla, our bugtracking (and request-tracking) software that we use to organize, prioritize, and keep track of all of our projects from major to minor. We use Bugzilla to keep track of our bugs and bug discussions, and Github to keep track of our changes and accept any submitted changes. If you have a change to submit for something that isn't on the list already, create a bug for it, then submit the change via a pull request.

See also Suggestions Process for community discussion of proposed changes.

Registering a Bugzilla account

In order to report bugs or submit patches, you will need to register a Bugzilla account by providing an email address. Note that this email address will be your username for login, and it will be visible in the bug reports.

After registering your account, we ask that you go to the account preferences and edit your "real name" to include your DW username, like so:

My Preferred Name [:dwusername]

(Your "real name" as displayed in Bugzilla is visible to the public. It can be anything that you're comfortable associating with your DW username and having other developers address you by.)

You can also edit other Bugzilla display preferences, email preferences, and saved and preset searches to display.

If you are going to submit patches, contact denise (denise@dwscoalition.org) if you have already sent in your Contributor Licensing Agreement, so she can set the appropriate flags for your account. We won't be able to accept anything you submit until we have the CLA on file.

Opening a ticket

Go to the page to create the bug. You will first be asked to pick a Product:

Most of the time, you'll use Dreamwidth Development: this is for everything having to do with the Dreamwidth code product (features, usability, bugs, etc). If you're reporting behavior on the site, it goes here. Example: "Display problem on the front page".

Project Documentation is for anything to do with the contents of the documentation system: request for a new FAQ, request for a change to an existing FAQ, suggested phrasing, and drafts. Example: "Misspelling in FAQ 404!"

If your item specifically relates to the business of Dreamwidth Studios, LLC, use "Dreamwidth Studios, LLC." Example: "Renew business license." If your item relates to the operation of dreamwidth.org (such as sysadmin tasks, etc), use "Dreamwidth.org Site Operation". Example: "Order and provision another server."

You will then be taken to the next page, where you must fill in three fields: Component, Summary, Description

For "Component", pick your best guess as to what your item deals with. (We populated that list with a set of guesses about what most of the items would be categorized as.) If it straddles two items, pick one. Flip a coin if you have to.

For "Summary" briefly describe the bug. It should state what is wrong, and not your desired solution.

"Description" is where you can put the rest of the details. Include steps to reproduce if possible / applicable. HTML will be automatically escaped, so you can enter HTML tags in order to show a bit of code, but not to format your responses. Here's a sample template, for frontend bugs to get you started.

Don't worry about the other fields if you are not sure what to enter for the rest. Someone else will come through and set all the flags, so you don't have to worry about them unless you really want to.

Other fields, briefly:

Lower number (higher priority) are more urgent. If you don't have a good idea of how to prioritize your request, leave the Priority field set to P- (unset).

If you're proposing a new feature, or sweeping changes to an existing feature, and you need someone to write a spec for it, set the "needs-spec" flag to "?". If you have someone in particular in mind to write the spec, enter their Bugzilla email address there; if you just want anyone to do it, leave that field blank. If you need the help of someone to do visual design, set the "needs-design" flag to "?".

Now that the beta phases are over, there is no need to set any blocking flags.

Categorizing the bug

Mark or Denise (or someone who has been delegated a project-manager role, in the future) will make sure that your item is properly prioritized and categorized.

Adding an attachment (design or spec)

If you're doing design work or a spec for a bug, upload it as an attachment and set the "needs-signoff" flag to "?". By doing this, you're requesting approval from Denise or Mark for your design or spec. They'll either grant this approval by setting the flag to "+", or set the flag to "-" and request specific changes. Be sure to also add your email address as a CC on the bug, so you receive any requests for changes. However, unless you plan to program the patch, don't assign the bug to yourself; leave it to the default assignee of (nobody@dreamwidth.org).

Claiming an item

If you're intending to code a patch to satisfy the item, assign the item to yourself. Do this by editing the "Assigned to" field and entering your email address. Then set the Status dropdown (first dropdown) from CONFIRMED to IN_PROGRESS.

When you commit (save) this, a whole bunch of people will be emailed. Don't freak out. They willingly signed up for emails from Bugzilla.

Now that you've claimed the bug, you can make and submit your changes as per Version Control.