My MeeGo bugtriaging experience so far

But it happened that it was early October and that I felt like diving into MeeGo bugtriaging. After some public whining, Carsten (who’s always a huge help) and Dawn were kind enough to point out the existence of the meego-qa mailing list. I subscribed.

At that time there also was a wikipage with a list of names (“Contact the first person in the team” without any hints how to) and an IRC channel (#meego-bugs on Freenode) with one or two people but not much feedback.

Being in a JFDI mood I moved some wikipages (related information was split under wiki.meego.com/Quality and wiki.meego.com/Bugzilla) and asked some questions on the mailing list. Some have been answered, others haven’t.
I sometimes wondered if either QA engineers don’t know answers or if QA management prefers to remain silent to avoid making decisions, or if a few people just consider documenting their workflows and communicating what they are working on in public a waste of time.

What has changed:
I set up a triage guide.
The bugtriage meetings are now on IRC, in public.
The wikipage looks way better, things have become more transparent in general, and the IRC channel constantly has some people lurking around.
On a related note, the QA talk at MeeGo conference was particularly helpful to get the broader picture of all the MeeGo QA tasks and to realize that bugtriaging is just a small part of the picture.

Next on my list is to start collecting stock answers (like in Maemo) which requires help from triagers having specific knowledge. However, as I like to sort them by Bugzilla products, I am a bit reluctant as Eric said that the classification and product structure in MeeGo Bugzilla will probably change a bit after deploying Bugzilla 3.6.

Still there is enough to do and I am not happy with the current “openness” state. Remaining unanswered questions that I cannot “solve” myself as I miss information:

  • Who “defined” who became/is a triage team lead (=first person in each of the triager lists)? Were there elections, was it a decision of the companies involved, or was it meritocratic?
  • Why should I add my name to the triager lists as I could also triage without adding my name to a wikipage? What obligations are connected to adding my name?
  • What is concretely the job of “triage team leads” in contrast to “normal” team members? Why was a hierarchy considered as needed and introduced?
  • Documented permission requirements are missing. For example feature requests in bugs.meego.com cannot be fully edited without permissions (e.g. “Summary” line is non-editable). I don’t want to discuss the usefulness that I cannot fix typos in summaries because of that, but I’d like to see this documented in the wiki at least as I might not be the only person who was initially confused by it. I can’t document it myself as I don’t know the exact reasons behind this.
  • What does “Error Manager rights on MeeGo Bugzilla” actually mean? Filed a bug report, no progress yet. Feel free to vote.
  • Missing policy when to completely block access to a report and when to just mark specific comments as private – See my posting.
  • Difference and handling of “enhancement” severity vs. “MeeGo Features” classification and documenting the explanation in the wiki.
  • There is a list of code customizations for MeeGo Bugzilla. Are the source code patches somewhere available? Have they been upstreamed or submitted as patches in bugzilla.mozilla.org (in case that it makes sense)? If not, why not, and is it planned to do so?
  • Where to handle MeeGo Extras/Surrounds apps bug reports? – See posting here.

One Response to “My MeeGo bugtriaging experience so far”

  1. Dawn Foster says:

    And we appreciate all of the help and hope you continue to push on getting answers to the rest of those questions. :)