Bug Report Workflow (Support)

Note: This is currently a proposed policy that is open to comment.

Currently a significant number of support requests are related to site functionality, many of which may be actual bugs. Most bugs are known, but since this is such a common source of inquiries we need to be able to handle them quickly to keep our stress levels down and our users happy! With this in mind, follow these steps to ensure a consistent, timely approach.

If you have ideas for improving this policy, add them to the Discussion Page or contact invisionary directly. (skrshawk on IRC)

doors.txt;10;15

Bugzilla Reporting Workflow

The entire Bugzilla workflow (which goes from bug reporting to committed patch) can be found here: http://wiki.dwscoalition.org/notes/Bugzilla_workflow . The full article is good reading so you have an understanding of the entire development process. Here is a simplified version focusing on bug reporting. If you'd rather follow the primary document, the first three steps are what you need to know. Otherwise, read on.

1. To log a bug you will need a Bugzilla account. Anyone can make one, so follow the simple process. You don't need an account to search and view bugs, however. Go here to create your account: http://bugs.dwscoalition.org/createaccount.cgi

2. Create the bug here: http://bugs.dwscoalition.org/enter_bug.cgi.

Select a queue for your bug. Generally you're going to want the Dreamwidth Development queue. If the bug is related to something that needs to be better clarified in the FAQs or elsewhere in the site copy, use the Project Documentation queue. The next screen is the main bug entry page. Fill in the following fields:

Component: Most of the time UI/Frontend is the nature of the bug, but use other options as appropriate.
CC: Add your email here if you want to track progress of the bug.
URL: The page (if appropriate) where the bug is happening.
Summary/Description: Fill these in with as many details as you can - you should have plenty from your interaction with the user and other support people.
Severity: Most likely the highest severity you'll need to use is minor, which is what you want if you suspect a bug affect a significant number of users. Any higher than that should be significantly affecting site usability - if so, talk to a senior about it (or check with IRC).
Priority: You'll want to stick with P4 or P5. If you suspect a bug warrants a higher priority, again, talk to a senior (or mention it in IRC).
Tags: Stick to the existing tag list. The tags are intuitive; use what's most appropriate.

Flags: You may wish to use need-spec or needs-design for enhancements that aren't fully fleshed out. Spec is for enhancements that need thought as to just what should be done; Design is for enhancements that might need thought put into the visual/frontend elements. Set either to ? as appropriate.

3. Hit the commit button and watch it go into the queue (and Bugsy report it in #dw!). Be prepared to field further questions from the devs if needed - don't worry, we don't bite unless asked nicely!