Identifying projects and localization teams in need / GUADEC 2010

The talk (at GUADEC).

Apart from the usual Release Team service announcement and its charming follow-up street fights and the two short Bugsquad and Localization reports at the AGM meeting I also had the pleasure to present a talk about something that I’ve been thinking about for a while:

My theory in short: We lose people that attach patches in Bugzilla to dead modules and never get a response. We waste time translating/localizing modules that will never see a release again. We are stalled as we have always been around 50 “supported” languages for the last GNOME releases. And we need ways out of all this.

For those who could not attend my talk and for further investigation, its slides (pdf/odp), data (cvs/odt) and code (sh) are available. The hardest part really is to find the meaningful data in all that noise. While I plan to continue thinking about this any input is welcome.

The translations (L10N).

For the translations part of my talk, as a first step the Releases Comparison table could get a neater URL and another column that calculates the difference in coverage between the last two years, plus linking the entries in the Languages column against the corresponding teams (yes, teams). Teams that lost more than 10% coverage in the last 2 years are: mk, dz, sq, si, ne, en_CA, cy, hr, fa, vi.
Another data source are those languages with no Git activity (0-2 commits in the last 2 years: an, bal, bem, dv, ff, fur, gn, ha, km, ks, ky, nap, tg, yo, zh_trad, zu; 3-20 commits: en_AU, ha, kk, la, ug).
Contacting these drowning translation teams / maintainers in order to ask for problems or if they still have enough time could for example be handled by the Coordination Team.
In case of no response a translation team can be considered dead.
Now one could take a look whether some contributions exist in damned-lies by people that could be interested to become the new coordinator. And/or downstream teams could be contacted and asked whether they are interested in contributing in upstream GNOME, e.g. teams in Fedora, openSUSE, Ubuntu or other distributions.
While becoming the new translation team coordinator is usually handled quite quickly on gnome-i18n mailing list once it is clear that the old coordinator is not around anymore, changing the assignee data in GNOME Bugzilla and getting Git commit access usually take a bit longer and could currently be demotivating bottlenecks. Time to review the rules or to have a survey about this?

The modules (Git).

For the modules part of it, two warnings could be added to Bugzilla, damned-lies and when checking out via Git for those modules that have not had much activity lately in GNOME Git.
Maintainers of modules that have not seen any commits for a long time (two years?) could be contacted to get a statement about the module’s status (this was done in the past already with mixed results). In case of no answer or a negative answer this could mean “Note: This module is obsolete or abandonned. No work is planned to take place and you might waste your time by filing a bug report or attaching a patch here”.
If we don’t know (yet) this could mean “Note: This module has not seen much activity in the code repository lately” (plus a hint what to do). Of course this first needs a definition for time period and commits thresholds in order to define “not much activity lately”. This could warn patch contributors in Bugzilla to either be patient for a patch review or to contact the maintainer first and it could help translation teams to set priorities and not to translate inactive modules. Another email contact should be provided (probably not the release team but a new team in GNOME?) for the potential case that the maintainer does not respond. However technically I don’t know where the Git activity results could be cached in order to not continiously be queried by several other parts of GNOME’s infrastructure.
As written before, comments, ideas and criticism are welcome. This is still an early stage.

GUADEC (In general).

And to talk in general about GUADEC: As usual it felt like holidays but I finally managed to not spend the entire day at the conference venue in order to also see a bit of the city (like the ICJ, the Scheveningen beach and the city center on Saturday). It was great to have my girl with me and to meet with old and new colleagues of the Openismus crew. And I had interesting chats with Amir H. Moin about datamining and the Evolution crew about non-coderelated stuff, both while lying on a beach couch.