GNOME 3.36 user documentation updates

Looks like since the release of GNOME 3.34.0 in September 2019 I made exactly 500 commits in GNOME Git. :)

Localized screenshots shipped in GNOME 3.34 versus the same screenshot in 3.36

Localized screenshots shipped in GNOME 3.34 versus the same screenshot in 3.36

  • My main focus was on updating documentation. The user help of cheese, gnome-klotski, gnome-mahjongg, gnome-nibbles, gnome-robots, gnome-terminal, gnome-tetravex, iagno, lightsoff, quadrapassel, rhythmbox, zenity should be up-to-date in 3.36 again.
    (If not, then report issues in GNOME GitLab with the label “8. User Docs” or contribute patches yourself.)

  • This also included updating a majority of outdated screenshots (both English and localized versions when feasible) across projects.

  • I also took the liberty to push quite some trivial markup fixes in some translations when a language was not already reserved for translation on GNOME’s translation platform (as such actions would interfere).

Enjoy 3.36!

Posted in gnome, lang-en, user-documentation | 3 Comments

Prioritization of bug reports and feature requests in Free and Open Source software projects

A few months ago I wrote an essay on software development planning in FOSS projects. It tries to answer the following questions:

  • Why has nobody fixed this issue yet?
  • Why wasn’t I consulted about these changes?
  • How I can influence what is worked on?

Some parts of the essay are specific to Wikimedia but I hope it can also be useful for other communities. It is published under CC BY-SA 3.0 so feel free to remix.

If you have a similar document for your project, please feel free to share a link in the comments.

Posted in bugzilla, computer, gitlab, lang-en, phabricator, wikimedia | Comments Off on Prioritization of bug reports and feature requests in Free and Open Source software projects

Updating some GNOME 3.32 user documentation

Apart from replacing many broken links to or replacing links to GNOME Bugzilla with links to GNOME Gitlab in many code repositories and wiki pages, in the last months I spent some good time updating random GNOME user docs all over the place:

Rhythmbox comparison

  • The user docs for Rhythmbox 3.4.3, GNOME Chess 3.32, five-or-more 3.32 and four-in-a-row 3.32 should be up-to-date.
  • The Totem 3.32 user documentation is up-to-date and now in Mallard format, based on work started in 2013 by Magda and Kat.
  • The screenshots in the user help of gnome-klotski, simple-scan, swell-foop, tali, and zenity are up-to-date.
  • Updated hopefully all places which mentioned an application menu now replaced by a menu button.
  • Removed a bunch of unused help images from some repositories shipped for no reason and bloating tarballs.

Enjoy and check the GNOME Wiki if you are interested in working on user documentation!

Posted in gnome, lang-en, user-documentation | 1 Comment

GNOME Bugzilla closed for new bug entry

As part of GNOME’s ongoing migration from Bugzilla to Gitlab, from today on there are no products left in GNOME Bugzilla which allow the creation of new tickets.
The ID of the last GNOME Bugzilla ticket is 797430 (note that there are gaps between 173191–200000 and 274555–299999 as the 2xxxxx ID range was used for tickets imported from Ximian Bugzilla).

Since the year 2000, the Bugzilla software had served as GNOME’s issue tracking system. As forges emerged which offer tight and convenient integration of issue tracking, code review of proposed patches, automated continuous integration testing, code repository browsing and hosting and further functionality, Bugzilla’s shortcomings became painful obstacles for modern software development practices.

Nearly all products which used GNOME Bugzilla have moved to GNOME Gitlab to manage issues. A few projects (Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy) have moved to other places (such as Gitlab, self-hosted Bugzilla instances, or Github) to track their issues.

Reaching this milestone required finding, contacting and discussing over the last months with project maintainers of mostly less active projects which had used GNOME Bugzilla for their issue tracking.
For convenience, there are redirects in place (for those websites out there which still directly link to Bugzilla’s ticket creation page) to guide them to the new issue tracking venues.

Note that closing only refers to creating new tickets: There are still 189 products with 21019 open tickets in GNOME Bugzilla. IMO these tickets should either get migrated to Gitlab or mass-closed on a per-product basis, depending on maintainers’ preferences. The long-term goal should be making GNOME Bugzilla completely read-only.

I also fixed the custom “Browse” product pages in GNOME Bugzilla to get displayed (the previous code expected products to be open for new bug entry). Should make it easier again for maintainers to potentially triage and clean up their old open tickets in Bugzilla.

Thanks to Carlos and Andrea and everyone involved for all their help!

PS: Big Thanks to Lenka and everyone who signed the postcard for me at FOSDEM 2019. Missed you too! :)

Posted in bugzilla, gnome, lang-en | Comments Off on GNOME Bugzilla closed for new bug entry

Wikimedia in Google Code-in 2018

Newcomer and Mentor sticker designs

Newcomer and Mentor stickers designed by GCI 2017 participant Ashley Zhang, CC BY-SA 4.0.

Google Code-in (GCI) is an annual seven week long contest for 14–17-year-old students exploring free and open source software projects. Organizations, such as the Wikimedia community, offer small tasks in the areas of code, documentation, outreach, research, and design. Students who complete tasks receive a digital certificate and a shirt from Google. The top students in every participating organization win a visit of Google’s headquarters. Students can directly experience how large online projects are organized, collaborate with humans across the planet, and the students’ accepted work is made available to millions of worldwide users.

For the sixth time, Wikimedia was one of 27 participating organizations which offered tasks mentored by community members.

In late 2018, 199 students worked on 765 Wikimedia tasks with the help of 39 mentors. To list only some students’ achievements and show the variety of projects, areas, and programming languages in the Wikimedia community:

…and many many more.

Some students have also written about their experience. Google also posted a summary with statistics.

We would like to congratulate our winners Nathan and Shreyas Minocha, our finalists arcaynia, Jan Rosa, takidelfin and Zoran Dori, and all contributors on their many contributions! We hope to see you around! We would also like to thank all our mentors for their commitment to be available also on weekends and holidays, for coming up with task ideas, working together, quickly reviewing contributions, and for providing feedback what we could improve next time.
Thanks to everybody on IRC, Gerrit, Phabricator, mailing lists, Github, Telegram for their friendliness, patience, support and help.

Wikimedia always welcomes contributions to improve free and open knowledge. Find out how you can contribute.

Posted in lang-en, wikimedia | Comments Off on Wikimedia in Google Code-in 2018

Google Code-in 2018 and Wikimedia: Mentors and smaller tasks wanted!

Google Code-in will take place again soon (from October 23 to December 13). GCI is an annual contest for 13-17 year old students to start contributing to free and open projects. It is not only about coding: We also need tasks about design, documentation, outreach/research, and quality assurance. And you can mentor them!

Last year, 300 students worked on 760 Wikimedia tasks, supported by 51 mentors from our community.

  • Your gadget code uses some deprecated API calls?
  • You’d enjoy helping someone port your template to Lua?
  • You’d welcome some translation help (which cannot be performed by machines)?
  • Your documentation needs specific improvements?
  • Your user interface has some smaller design issues?
  • Your Outreachy/Summer of Code project welcomes small tweaks?
  • You have tasks in mind that welcome some research?

Note that “beginner tasks” (e.g. “Set up Vagrant”) and generic tasks are very welcome (like “Choose and fix 2 PHP7 issues from the list in this task” style).

If you have tasks in mind which would take an experienced contributor 2-3 hours, become a mentor and add your name to our list!

Thank you in advance, as we cannot run this without your help.

Posted in lang-en, wikimedia | Comments Off on Google Code-in 2018 and Wikimedia: Mentors and smaller tasks wanted!

GUADEC 2018 (It’s a Gitlab world)

Proč? Proto!

Karlovy Vary – Ankali.

GUADEC in Almería was a great opportunity to catch up with some technologies in the GNOME world, hang out with lovely folks again, and spend time at the beach.

  • Wrote stock answers / canned replies for GNOME Gitlab (to be used in your local browser as a user script) as stock answers are not supported yet by default in Gitlab.
  • Realized that I can still directly push into Git repositories hosted in GNOME Gitlab. Also created my first proper merge request after forking in Gitlab. Workflows.
  • I finally removed GNOME Evolution’s ancient Quick Reference PDF, after Raniere Silva had moved the list of keyboard shortcuts into the Evolution user help (thanks for your patch!). Also fixed a good bunch of Evolution user documentation issues.
  • One last time: Presented Bugzilla activity statistics at the AGM.
  • Closed about 2500 open tickets of unmaintained products in GNOME Bugzilla.
  • Had a GNOME Release Team meeting.
  • Realized that Sébastien and I enjoy the idea of better development statistics. As volunteer time is too precious to reinvent wheels:
    • A shell script to pull and/or update all Git repositories in GNOME Gitlab
    • Print the date of the last non-translation commit (translation commits are located in the /po subdirectory) in a git repository: git log -n 1 --pretty=format:"%cd" --date=short -- !(po)
    • Print the number of non-translation commits since a certain date: git log --after=2010-07-10 --pretty=oneline -- !(po) | wc -l
    • Print the number of different non-translation committers since a certain date: git log --after=2010-07-10 --committer='' --pretty=format:"%ae" -- !(po) | sort -u | wc -l
    • Print the email addresses of people listed as maintainers in a project’s DOAP file: xmlstarlet sel -N doap="" -N rdf="" -t -v "/doap:Project/doap:maintainer/foaf:Person/foaf:mbox/@rdf:resource" somename.doap
  • Carlos was kind enough to tell me about Quick actions in Gitlab plus keyboard shortcuts, to save me some triage time. Plus to answer all my Bugzilla to Gitlab related questions (or concerns?) as I had not followed closely for the last months…
  • …which also made me curious how far GNOME has already migrated from Bugzilla to Gitlab (kudos to Carlos, Andrea, Alberto, the Gitlab crew, and everybody else involved in planning and performing this move!) so I decided to gather some numbers yesterday:
    • 265 products in GNOME Bugzilla have zero open tickets, do not accept filing new tickets in Bugzilla anymore, and do not exist in Gitlab either. Ancient stuff. Nothing to do.
    • 103 products in GNOME Bugzilla have zero open tickets and do not accept filing new tickets in Bugzilla anymore as you get redirected to Gitlab. Either already fully migrated or small projects. Nothing to do.
    • Doxygen has 1908 open tickets in Bugzilla, does not accept new tickets in Bugzilla, and does not exist in Gitlab.
    • 17 products in GNOME Bugzilla have zero open tickets and do accept filing new tickets in Bugzilla. That’s projects to still set up in Gitlab, I’d say.
    • 197 products in GNOME Bugzilla have 23426 open tickets in total and do not accept filing new tickets in Bugzilla anymore as you get redirected to Gitlab. That’s tickets to either mass-migrate from or close with an explanation in Bugzilla, I’d say.
    • 51 products in GNOME Bugzilla have 5791 open tickets in total and still accept filing new tickets in Bugzilla. That’s products and tickets to set up in Gitlab and either mass-migrate from or close with an explanation in Bugzilla, I’d say.
Posted in bugzilla, gitlab, gnome, lang-en | 2 Comments

Statistics, Google Code-in, Gitlab, Bugzilla

Posted in gnome, lang-en, metrics, user-documentation, wikimedia | 1 Comment

2017: Music.

That annual list of awkward incomplete pop music preferences: Stuff I listened to a lot in the last 12 months. Which did not necessarily get released in 2017. But mostly, I think. And/or enjoyable gigs.

Noga Erez‘ debut album and Zagami Jericho‘s first EP are my favs.
Followed by the latest release by Moby & The Void Pacific Choir, Sevdaliza‘s debut, and Bulp‘s first album.

Looking back at sets, Recondite, Helena Hauff and Setaoc Mass were long nights that left marks.

Looking back at concerts, EMA, Waxahatchee, Lali Puna, Moderat.
Ufomammut and Shobaleader One were banging.
Being able to see Battery live, after all those years.
Someone please send Days’n’Daze on a European tour.

I’d like to thank my bunch.
It’s been a special year, in many ways.

Posted in lang-en, music, non-technical | Comments Off on 2017: Music.

Handling all those mail notifications from the bug tracker

…and following stuff that interests you in an issue tracking system.

I work as a bugmaster in a large project. That means I interact with many people on many topics and try to have a quite hollistic view of what’s going on which requires processing vast amounts of information. Apart from good memory and basic technical understanding (“Wait, this report reminds me of another one which might be related”) I need to follow up and keep track of stuff.

When talking to fellow Wikimedians a common question I receive is: “How do you cope with being subscribed to basically every task in our bug tracker (Wikimedia Phabricator) and receiving those notifications?”

Assuming there is often “How can I cope with all that mail I receive?” hidden between the lines, I’m going to cover that first:

Phabricator options which allow you to follow or collect a list of stuff which interests you:

For completeness: Currently Phabricator does not offer a difference between “I subscribed to this task or got subscribed as I watch the associated project” versus “I got explicitly mentioned in a comment in this task” which can sometimes be unfortunate.

My mail workflow

My workflow is email based. Currently I actually take a look at about 400 to 700 bugmail notifications on a normal workday (I receive way more). Those are the emails that end up as “unread” in a subfolder of my email application (GNOME Evolution).

I apply filters locally, based on projects and/or senders (e.g. bots) of notifications. Phabricator includes a custom “X-Phabricator-Projects” header in every mail notification. As far as i know GMail does not support filtering on custom headers and last time I checked, GMail had a rather “creative” IMAP implementation which did not allow to perform such filtering server-side.
In Bugzilla, managing filter rules was easier as a task has exactly one product and component; further associations are expressed via keywords or whiteboard entries for those who fancy additional UI elements. As Phabricator tasks can have between zero and unlimited projects associated, the order of my local filters (and their criteria) is important.
For some projects and some senders, these filters set the email to “read” status (as in “has been read”) so I might never see these emails.

View of my mail application

My default view is to display only unread messages, to order by message threads, and to display new messages on top.

When going through new (unread) messages I mark most messages as read (keyboard shortcuts are your friend). I keep some messages in “unread” message status whenever I plan to re-check or follow up at some point. I occasionally go through them and nag people.
For urgent tasks which need rechecking rather sooner than later, I mostly end up keeping open tabs in my web browser (if those tasks are not prioritized with the highest (“Unbreak Now!”) priority already anyway).

In addition, I also display some associated projects in the message list for faster orientation which software area the thread is about. I use labels for this, which is a gross hack. (I’d love to have an email application that allows displaying values of arbitrary header lines as a column in the list of emails.)

Obviously, such an email based workflow makes it hard to pass work to someone else for a limited time (the so-called “vacation” concept). Some mail services allow proxying though.

Expectations and service level

And the social part: As Wikimedia Phabricator is used by more and more teams (not only by engineering but also by chapters, to plan sessions at conferences, etc.), I clarified which service level to expect from me. So the page that describes my job says: As the bugwrangler cannot support every single project and task in Phabricator to the same extent, maintainers and teams are more than welcome to contact the bugwrangler to express support requests for managing their tasks.

Do you have better workflows or tips to share?

Posted in bugzilla, lang-en, phabricator | Comments Off on Handling all those mail notifications from the bug tracker