andré klapper's blog.

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.

Haven’t blogged for a while on MeeGo related stuff, probably because GNOME was way more crucial in the last weeks.

• Wrote a proposal for allowing 3rd party products to be listed in bugs.meego.com – see this bug report for the discussion. Still need to get into the loop with the rest of the folks doing the planning on this, like repositories etc.
• Worked on a document to make the Downstream-Upstream relation a bit easier to understand for MeeGo developers that might be new to working in open source / free software environments (and the corresponding expectations on collaboration).
• The meego-qa mailing list, probably not the only place for this observation: It sometimes feels like there is not much feedback on issues that get brought up and should be discussed and that people work in their chambers without any note to the public or early codedrop of what they are doing (like a one sentence email to drop on a public mailing list that might take you less than a minute but avoids duplicated work and opens up contribution opportunities). Sure, sometimes I feel like it’s getting better; still printing this and taping it onto your computer screen to learn it by heart might help you.
• Looks like our talk proposals (Bug’s Life, presentation of the bug’s life cycle and BoF Improving MeeGo Error Management Process and Practices) have been accepted for the MeeGo Conference which will take place in one month. Plus looking forward to yet another talk by the MeeGo EM crew.

And on an unrelated note: The MeeGo QA Dashboard beta looks pretty neat.