MeeGo QA and RE stuff I’d like to understand.

About some stuff that I’ve recently tried to find out in MeeGo.

Quality Assurance

• “Risk level” and “UX status” field in MeeGo Bugzilla was not documented anywhere – Bryan asked before, I asked again, and in the end “Risk Level” got removed. Yay.
• Initially I questioned the “Triaged by” field especially because it was introduced without any public discussion of its usefulness or announcement of its introduction at least. I can accept its existence but I would still like to know where the data will actually be used.
• Products in Bugzilla have been created without a default assignee to take care. I consider this a problem (“sort out first who will take care” as we do in GNOME Bugzilla) while others didn’t (“give testers the possibility to report bugs”).
• On a very related note there is an account named “need-triage@meego.com” (previously called “nobody@meego.com”) that bug reports can be assigned to. Asking about its usage I got told that this is “a critical indicator for project management” that resources are missing and also that “this should be fixed at project management level”. So I asked if efforts have been made to fix this on the project management level and if the data (tickets with this assignee) is actually used but have not received answers yet.
  Apart from the inconsistent naming (the domain “meego.bugs” looks more appropriate as virtual accounts of that format already exist in Bugzilla) this might now becoming the rotting /dev/null for all the reports that initially received a wrong assignee.
  As per June 9th, 38 non-closed tickets have the assignee need-triage@meego.com. Between 2011-03-04 and 2011-06-05 there have been exactly 3 tickets whose assignee was changed from need-triage@meego.com to somebody else, all of them in the Compliance product in one go. To me it is obvious that something does not work well. As opinions differ I asked for an interpretation of these numbers and am still waiting.
• Plans for a Bugzilla structure enhancement that were described in a BoF session at MeeGo conference. Still waiting for any documentation to review it but I might not have a chance as the bug report already has READYFORINTEGRATION status.
• Unhappy of restricting access to complete bug reports just because of one inappropriate comment added (for the definition of inappropriate check the wiki). Plus nearly always people restrict access without explaining why. I might enable marking only single comments as private soon.

Release Engineering

• Waiting for a comment by MeeGo’s Release Engineering team to my request to actually describe the process of handling release / update blocker bug report requests. I have not been the only one wondering.
• On top of it I’ve taken a quick look at response times and ratios of this process in Bugzilla. Also waiting for a comment on the numbers by Release Engineering.

Update: Received responses to my RE questions now.

It’s likely that this list wasn’t complete. I now might be too keen on documenting processes (that’s the “information vampire” pattern as Carsten calls it). Friends and colleagues providing their impressions and feedback by larting me in a friendly way is appreciated.

I have not used the word “transparency” in this posting but you can probably insert it at any place.