How do bug reports work?

Hi,

much kudos for the known issues page - really nice to have, and an improvement on complete silence, but.... I have a few outstanding bugs that I've reported, including ones that have been acknowledged, that don't show on it - at least not that I can find.

I also know that you (quite rightly) don't list exploits or other such nasties on the page.

Given that you use RT as a ticketing system, and that it has configurable security at a user level, would it be possible to set it up such that people who submitted the bugs (and therfore already know how to repro them) could get (even read only would be good) access to its web ui so that we can track our issues?

Write access would be even better, since we could post updates to it and be sure that they were in the system, since the stony silence that greets you when you email an update back into RT always leaves me wondering if the mail has actually ended up in /dev/null somewhere along the line.

If the way you have it set up wouldn't support this without major reworking, then it probably isn't worth it, but, well, I just wondered, seeing as the security and web interface features are already there in RT, then, maybe?

First, thanks for the kind words about the Known Issues page! Second, RT doesn't work that way. Here's how the workflow goes:

WARNING: Long-winded post ahead!

- Resident reports a bug via Help > Report Bug (or emails [email]bugs@secondlife.com[/email]).
- RT tags the report and sends out an auto-response with the RT #.
- QA puts on the hazard suit, dives into the RT and starts throwing bugs around, looking for the good ones (think of a pile of socks as big as Mt Shasta. Most of the socks have no matches and the one you're looking for is somewhere in the middle, next to the red t-shirt your mother told you never to wash with socks...)
- QA finds your sock, can actually read it and the repro works.
- The bug is entered into our internal tracking software and assigned a priority.
- QA determines if the bug is "Safe for Public". The criteria for a SfP bug are:
- Is the bug an exploit? NO: Go on.
- Is this bug reproducible? YES: Go on.
- Does the bug affect systems that are visible (ie, this isn't some arcane server side thing that won't make sense)? YES: Go on.
- Any email addresses/resident names/specific assets in the bug report? YES: Clean them! None of this should be in the repro (unless the asset triggers a bug serious enough and widespread enough to warrant its name inclusion in the repro -- free items will receive much less scrutiny in this department) NO: Go on.
- If QA determines the above then the bug is marked Safe for Public and a Public Repro is devised which usually differs from the original repro. We take time to create a repro case that is both easy to understand and (when possible) automated by a script, reducing the possibility of user error. We also change the title of the bug. Almost every bug we enter gets a new title so it makes sense to both residents and our developers.
- QA tags the RT with the internal issue tracking number (the SL-#### numbers you see on the Known Issues page). This doesn't get emailed to the reporter.
- Bug gets tagged as "Resolved" in RT and you may (depending on how busy the QA guy is) get a "Thank you, bug entered!" email.
- QA guy climbs out of RT, shakes the socks off (curse you, static cling!) and after a bit of time detoxing (read: Street Fighter 2) goes back to busting things in an internal grid.
- Now that the bug is in our internal system, we vote (internally) on lower-priority bugs which can lead to the elevation of the bug's priority. We do this because something that doesn't seem like a big deal to a non-building Linden could be a huge catastrophe for a Linden who builds (and thus, all builders in Second Life).
- The bug eventually gets picked up by a developer. QA also will advocate for a bug's fix if the perceived need is greater than usual, which can lead to a dev taking it on quicker.
- Linden Lab does not disclose the status of a bug (is it going to be fixed? when will it be fixed?) -- which can be pretty frustrating.
- After the developer marks the bug "Finished: Resolved" they request a build to be done to an internal grid.
- QA then verifies the fix in the build, which *only* contains this fix.
- Once the bug is verified as fixed in the build, that branch gets merged into a Preview branch.
- QA again verifies the bug in the Preview branch.
- If a bug does not pass this level of verification, it's either fixed if there is time or backed out of the Preview so it doesn't affect the release window.
- Safe for Public bugs that are verified as fixed in a new version will be posted to the Release Notes and removed from the Known Issues page after the version goes to the live grid.

It's important to note that replies to RT *do* get back to us -- as long as they are replied to between those little lines (read the RT autoresponse for instructions on how to reply to an RT email). If its useful for the bug report we'll add the info into the internal tracking system. Usually we'll reply back but we get really busy . I'll personally try to respond back to RT replies more.