Publishing my usual list of awkward and never complete pop music preferences of 2015.
In this year’s edition of Google Code-in, students can choose from tasks provided by the following organizations / projects: Apertium, Copyleft Games, Drupal, FOSSASIA, Haiku, KDE, MetaBrainz, OpenMRS, RTEMS, SCoRe, Sugar Labs, Systers, Ubuntu, and Wikimedia.
If you are a 13-17 year old pre-university student interested in getting involved into free and open source software development, check out Google Code-in.
It is a great opportunity to learn about distributed software projects, to find out which areas of software development you are interested in, to gather some on-hands experience, to contribute to “real” projects out there used by millions of people, and to make new friends all over the world.
Wikimedia is an organization which has both volunteers and paid folks working together in software development, with many software projects and different stakeholders involved.
In Wikimedia, there is currently some discussion how to improve the code review process. One aspect is reducing our code review queues and waiting times, with a focus on contributions provided by volunteers.
There are numerous successful free and open source software projects with a similar setup of companies and volunteers involved (Mozilla, Openstack, …) so I’m curious if your project has also investigated similar questions and if there is some knowledge and experience to share.
- In your project, do maintainers commit to review contributed patches in a certain timeframe, like “all patches receive a first review comment within four days”? How is this process implemented? Do you think it is successful?
- With an existing backlog of patches that did not manage to attract a review, what do you with ancient and rotting patches? Do you just abandon them after a certain timeframe in your code review tool to get a “cleaner slate”? Or do you leave them open to (theoretically) allow someone to find them and them pick up?
- Do you have any specific workflow in place that provides feedback to patch authors who contribute a patch to a rather unmaintained repositories that noone feels responsible for (anymore)? Do you signal the lack of maintainers and encourage contributors to step up as maintainers? How?
- Do you have a workflow in place to specifically prioritize the review of patches contributed by volunteers? How efficient is it?
I’d be very interested in hearing how your project handles these issues. Needless to say, links to documents are welcome. Thanks!
- Seven months after migrating from Bugzilla to Phabricator (and keeping Bugzilla available for login to access personal votes and saved searches while making all tickets read-only), we killed Bugzilla for good in May 2015. One tool less to maintain.
John and Daniel turned Bugzilla tickets and their activity/history into a static HTML version at static-bugzilla.wikimedia.org. That static and sanitized database dump was created to keep some historical changes available, for example historical changes to the priority of a ticket were not imported into Phabricator but only the Priority value at the moment of migration. Researchers might also be interested in that (or not).
Nemo was kind enough to use that data dump and import it into a read-only Bugzilla instance on Wikimedia Labs again which also includes tickets’ votes at that time.
- Furthermore, no Wikimedia teams are left using Mingle for task management and planning – all moved to Phabricator. We still have a small number of Trello users though.
- Wikimedia Deutschland is working on Phragile (for agile project planning) to replace the custom Phabricator Sprint extension in the long run.
- Two weeks ago, Wikimanía 2015 took place where (among a billion other things) Andrew and I gave introduction talks to the Wikimedia tech infrastructure (we plan to turn that into a generic script that anybody could follow). I also gave an introduction to Wikimedia Phabricator and joined the Community Engagement panel discussion. In general: Great people in the Wikimedia community and great conversations. (Plus need to go to Mexico City again to see more of that.)
- As usual, Phabricator upstream development is moving fast. Upstream now provides Spaces to isolate access areas. Once we’ve set this up (work in progress) in the Wikimedia instance, this will help some of our non-engineering teams to manage tasks that are not (yet) meant for public.
Tech Community Metrics
Again, all this is work in progress and needs way more fine-tuning (see our project workboard).
Continuing with the first day: Shobha Tyagi elaborated on the acceptance problems when moving users from Microsoft Windows to Linux based systems at her university. That talk resulted in interesting follow-up discussions on regional differences.
Later on, lightning talks took place.
On the second day, Alexandre Franke explained the GNOME release cycle.
Kukuh Syafaat showed how he uses his guitar, keyboard and computer running Ardour, Guitarix, LMMS and the JACK audio connection kit to make music with GNOME.
And Yantisa Akhadi presented OpenStreetMap’s impressive improvements in covering Asia, often leaving commercial map services like Bing or Google far behind.
The second day ended with a thunderstorm. It created a refreshing breeze in the main hall and made the frogs speak up outside the hall.
Again, kudos to the organization team (great work!) and thanks to the sponsors!
GNOME.Asia and GUADEC
This was the fourth GNOME.Asia summit I attended. Compared to GUADEC (the annual European conference), GNOME.Asia seems to have more fluctuation among attendees (as travelling can be more expensive in Asia due to its size and flight costs in comparison to costs of living?). There also seem to be more attendees that show up being curious what that international conference at the university is about, so it feels good to have some “how you can get involved” talks covering coding, documentation, translation, QA / bug triaging, engagement / marketing, …
GNOME.Asia summits also offer more talks with a regional focus. Would have loved to attend the “Open Source Software in the shoes industry” or “My experience as a farmer, trader and principle of village affairs in contributing to BlankOn” talks – unfortunately they were at the same time as my own talk.
Still it was a gift to speak with many community members while walking around, grabbing coffee or food, or just standing outside enjoying the sun.
It’s that time of the year again: GNOME.Asia Summit at Universitas Indonesia in Depok (Indonesia)! On Thursday some workshops took place how to contribute to GNOME translation and documentation and how to start coding.
Today (Friday) is Day 1 of the conference.
There were welcoming speeches by the local organization team, Kat Gerasimova of GNOME, Mirna Adriani, PhD (Dean of the computer science faculty) and Aidil Chendramata (from the Ministry of Communication and Informatics).
Later today I am going to give an introduction to handling (“triaging”) bug reports in GNOME’s issue tracking system.
A big thanks to the local organization team and the many sponsors of this conference for making this possible!
- The UNCONFIRMED bug status (which can be disabled per product) will be removed as it is mostly not used and confuses reporters. Tickets with UNCONFIRMED status will be merged into NEW status as announced on desktop-devel-list and at the top of every GNOME Bugzilla page.
If you are a GNOME project maintainer and want to keep the UNCONFIRMED status for your GNOME Bugzilla product you can opt out until the end of February.
- I encourage you to give the product pages and your user page a try!
They have become more useful:
- Target Milestones (if existing), Priorities (if actually used and not just kept as the “normal” default) and Severities are now listed first, to get a quick overview for those projects who might use Bugzilla to do some project planning (so far I have not seen that much though). Static information like components or versions now comes after.
- Versions now sorts by newest versions first. You should be more interested in bugs reported in recent versions.
- The previously shown needless NEEDINFO queries by date were moved to the side bar and merged into one query. The query results are sorted by last change.
- In the side bar, “Bugs without a response” is a link again (though it is not exactly what it says, it’s rather a query for reports with only a single comment, hence also a mismatch between the displayed number and the search result number when you click it)
- Moved “New Patches” into its own new “Patches” section under “New and unreviewed”. All patch related information for a project is now in a single place. Click it and review a patch!
- The “GNOME-love bugs” query shows reports that have been recently changed first – more likely that recently changed ones are not outdated and something new contributors could work on.
- The “activity” link next to “Git repository” could give contributors a quick idea how maintained the project is (only works if the project is hosted in GNOME Git).
- Your patches are now listed right after “What bugs are assigned to me” and “On which bugs do I need to provide input” and above the long list of “Open issues” that you once upon a time filed. Patches now also display the summary of the corresponding bug report. (Still have to remove the useless patch ID.)
- With above changes I’d like to make the “Browse Product” and “Describe User” pages give answers to “What is important?” and “What should I work on / review?”. I’d appreciate feedback if that’s considered helpful. For bugzilla.gnome.org itself this works pretty well, as you can see on its product page.
- Not yet available: I want the frontpage to look like this (thanks to jimmac for the custom icons; ignore the wrong color of the top bar):
This was already live for a few minutes but I reverted this change as the server started cycling through cached older versions (no idea what happened), plus I have the feeling that the skin handling is still problematic (my fearless guinea pig Shaun still had Bugzilla’s “Dust” skin enabled in his user settings so things looked pretty broken). Need to make sure that everybody uses the GNOME skin before doing further custom skin changes.
- 18 months ago I blogged a series of Bugzilla related posts. Though this focused on Wikimedia Bugzilla, there might be some helpful information or tweaks you are not aware of:
- Saved and shared searches
- Changing the columns in search results
- Creating reports and tables
- Autocompletion in UI fields
- Getting copies of another user’s bugmail
- Searching for empty fields
- Simpler searching for open tickets only
- Excluding less important reports from search results
- Reports: Tickets closed last week by resolution
Earlier this month, Quim Gil and I gave a talk at FOSDEM:
Wikimedia adopts Phabricator, deprecates seven infrastructure tools:
First hand experiences from a big free software project on a complex migration
The talk tried to cover three aspects: The decision driving process in a large distributed project, the technical and planning aspects of such a complex migration that nobody has tried before, and describing some of the functionality of the new tool (Phabricator) itself.
…and while I was playing with GNOME’s new Bugzilla instance trying to get rid of some upstream feature bloat, I looked at upstream’s Bugzilla front page and spend the next hours wondering where to add eight more Search buttons/links/forms so it’ll become a full dozen.
I mean, seriously?
Dear GNOME community, you all owe Krzesimir Nowak, Andrea Veri, and Olav Vitters some icecream and drinks: The Bugzilla software running on bugzilla.gnome.org has been upgraded to the latest stable version available.
- First of all: No amazing new custom features! But finally a maintained stable version of Bugzilla, without any larger customization regressions that I am aware of (smaller ones exist though, e.g. if your saved searches show zero results). After many years of being stuck with an old version.
If you want to read about new features, check out the upstream Bugzilla release notes for versions 4.4, 4.2, 4.0, 3.6.
- Technical information about the setup and upgrade is available, and further technical background (an interesting read) on porting all those custom extensions of GNOME Bugzilla can be found in Krzesimir’s blog.
- Also see the many issues that got fixed by upgrading to 4.4 (either via custom patches or pulling from upstream) and are not mentioned below in this blogpost.
- Note that the default Bugzilla email format is now HTML. If you dislike that, change it to Plain Text in your General Preferences.
- If you have a “Can we have a nicer theme?” or “Can we install Bugzilla’s kitchensink extension?” type of question, the answer might be “Sure, if you plan to provide that code and maintain it”.
So much for the general information that I am aware of.
And some smaller stuff that I was into
I was confused that some people saw me as a point of contact for the Bugzilla upgrade, as I did nothing apart from testing, some smaller tweaks, and providing grumpy input and feedback. Though I admit that lately I have performed some smaller taxonomy changes unrelated to the actual migration though:
- Standardized the “latest dev code” Version field value in GNOME Bugzilla to “git master”
- Mass-fixed components that had no default QA contact set (which we use for notifications based on User Watching).
- Disabled the “Severity” field value “trivial” and moved open tickets with trivial severity to minor severity.
- Disabled random obsolete components in several products (now any product maintainers can do that!).
…and some smaller testing and simple tweaks in Bugzilla itself on its way to 4.4:
- Common links on the frontpage: “Reported by and assigned to me”, “Created in last 5 days”, “Changed in last 5 days”. Maybe more to come, let’s see (the frontpage still has too much unhelpful stuff).
- The Patch Report shows the author and size of patches now (bug 675822). Maybe you are more motivated to review a patch if it’s a small chunk and if it’s an unknown contributor, or one that you trust?
- The list of your patches on your user page now displays the summary of the bug report.
- Improved and added some stock answers for triagers.
- Gerrit IDs in comments now automatically link to the commit (thanks to a hacking session with Olav; bug 559537). Requirement: Your Git repository name needs to match your Bugzilla product name.
Vague personal future ideas for GNOME Bugzilla
- Best development practices:
As I don’t see someone driving a discussion process to move GNOME to different (better?) infrastructure tools soon, I would like to make the custom “Browse product” and “Describe user” pages more useful for users to get an overview what’s there to work on and what is relevant (high priorities, new patches, target milestones) in a project. Many projects don’t really use Target Milestones or Priorities so far though I’m convinced it can be helpful if the tool properly supports you.
Regarding practices, I’d also discourage setting a default human assignee instead of a virtual assignee for components so the list of assigned bugs per user is actually what you yourself really plan to work on.
Furthermore, you probably do not want to set a default target milestone for the next version. It is just unrealistic and does not allow you to plan properly.
All such stuff, you know.
- Maintainers can be encouraged to disable old versions and target milestones: Dropdown lists become shorter. (Though not too short because users might still want to report issues in older versions. You do not help reporters if you disable the version they use – they might still report their bug but just not set the Version correctly.)
- Remove the “URL”, “Tags”, “Hardware” fields in bug reports. Feature creep.
- Another area that welcomes improvement is avoiding cookie-licking. Your user page lists the tasks which are assigned to you. Do you realistically plan (means: rough timeframe and actionable steps identified, and not just some “would be good” feeling) to work on those tickets assigned to you? Also, your patches are listed there.
Bugzilla also offers an overview list of open tasks per assignee (might load slowly) to see the full situation.
- A cronjob to dump taxomony changes into an email sent to Bugzilla maintainers as I am interested in consistency.
- Split the “docs” components of products into “User documentation” and “Developer documentation” components so it is easier for doc contributors to find tasks to work on. To discuss on d-d-l.
- Disable the “reviewed” patch status. It means nothing. Either a patch needs more work, or it is ready to go. To discuss on d-d-l.
- As the section heading says: Those are just ideas. They require discussion and time but you are very welcome to steal these ideas from me.
But what ever the future brings (or not):
You all owe Krzesimir Nowak, Andrea Veri, and Olav Vitters some icecream and drinks.