Archive for December, 2010

Evolution user documentation in Mallard

Thursday, December 16th, 2010

Two weeks ago I attended the GNOME Development Documentation and Tools Hackfest. Since then I’ve been working a bit on Mallard documentation for Evolution. It’s a complex task and I am happy that Barbara Tobias has offered her help. You can follow the development on gitorious.org. To take a look, clone it and run “yelp .” in the checkout directory.

Ignoring my own plan (something I already expected to happen when writing it up) I spent time thinking of structure and categorization of help topics and turned my “expressionist dance” drawing into a small but still confusing inkscape graphic that I’ve been enhancing over the last days while going through the old manual (the numbers in the picture refer to sections in the old manual):

Potential Evolution user help topic areas

Interesting sources for stuff to cover could be the FAQ, the old documentation (though the license is incompatible), the recent posts on the user mailing list, and recent bug reports that have been closed as INVALID (often because of misconfiguration issues or support questions instead of real software bugs).

I also hope to turn finishing some stub help pages into Google Code-In tasks. Yesterday I created the first task for documenting the search functionalities.

Help is welcome if you are brave enough to tame the beast.

Google Code-In in GNOME

Tuesday, December 14th, 2010

Google Code-In Logo

This is a short status report at half-time of Google Code-In 2010/11 contest (3 weeks have passed and another 4 weeks to go until January 10th).
Most of the students do an awesome job! Just to highlight some of the tasks that have been finished:

  • Translations: Lots of Greek and Romanian translations contributed – Nice boost.
  • Marketing: Initial “Getting started with GNOME development” tutorial; Initial guide to Berlin for Desktop Summit 2011 attendees.
  • Code: Some gedit plugins ported to libpeas; New gtksourceview languages files (Cobol, Go); Some pygobject patches; Snowy (see Natan’s latest blog post).
  • Usability: A survey comparing the keyboard shortcuts of common functions in 15 GNOME applications and the HIG.
  • Documentation: Vinagre and gnome-sudoku received initial Mallard formatted user help.
  • User Interface: Icon drafts for Anjuta and Vinagre.

Currently 84 tasks are finished, 12 ongoing, and 22 available for students to work on. And we still accept tasks! Click here if you want to mentor ideas that you have, or click here if you want to take part as a student!

Fedora 13→14…

Monday, December 13th, 2010

Decided to upgrade one of my machines this weekend.
While Fedora’s PreUpgrade is intelligent enough to check the free diskspace on / before downloading the new packages (at least according to the terminal output, bug 649399 states differently) it does not try to estimate if there will still be enough free space to actually extract and install them and will just cancel the process after the reboot (“You need more space on the following file systems: 224 M on /”, whatever unit “M” is meant to be). A bit late.

On / suspect areas to manually clean up are /tmp, /var/cache/yum (some data from older versions around) and /var/cache in general. Biggest packages that could be temporarily uninstalled were webkitgtk-debuginfo, gcc-debuginfo, openoffice.org and eclipse (not needed this time, but maybe next time?).

And apart from quite some typos in PreUpgrade strings (filed a bug) I of course also ran into probably all Evolution bugs that I could:

But apart from that I think I’m fine.

My MeeGo bugtriaging experience so far

Wednesday, December 8th, 2010

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.

bugs.maemo.org updated to 3.4

Wednesday, December 1st, 2010

As some might have noticed, bugs.maemo.org was upgraded from ancient version 2.22 to 3.4 last week. This means we now have a version running that is maintained upstream, a design that fits to the rest of maemo.org, less noisy comments, a frontpage that now states “This is a community issue tracker, sponsored by Nokia, not a Nokia communication channel”, and less complexity by e.g. hiding fields that normal users don’t ever need when filing a report. Plus we are not at the bottom of LPSolit’s list of Bugzilla installations anymore. ;-)

All kudos goes to Karsten Bräckelmann for lots of work (like applying the maemo.org wide theme, turning some image files into pure CSS, and tracking down ugly database transition issues), David King for continuing with finetuning and fixing missing pieces, and Ferenc Szekely for testing and deploying!

Today I finished updating my little Greasemonkey triage helper script for maemo.org Bugzilla so it should be functional again.

I also wrote an initial Greasemonkey triage helper script for meego.com Bugzilla that provides some common one-click stock answers and will display the email addresses of commenters and reporters by default (I like to spot immediately if a commenter has a corporate background).

(On a side note, yes, Mozilla Jetpack extensions are of course the future and to supersede Greasemonkey, like Matěj’s bugzilla-triage-scripts. That’s on the ever-growing to-do list.)