The threads are here and, here

And, to continue in that context is a post I made (on G+) . I strongly believe that the very fact of this bug being open and yet not bringing forth a discussion is something Mozilla should think about.

If you’d like to comment I’d request that you use the G+ link above and comment there.

• the load on each Ambassador Mentor ie. how many candidates are they mentoring in a specific period of time
• whether there is a need to sponsor and approve new Mentors
• whether there is a need to focus on regions from where there is a single or, no Ambassador
• the pattern, if any, in the reasons for the candidates whose applications to be a Fedora Ambassador is rejected
• whether there is a need and, a way the FAmSCo can get back in touch with such candidates and see if they can be coached to become Ambassadors (once rejected isn’t rejected forever)

I had earlier written about a few different things FAmSCo could look into. These are interesting times. The Wikipedia Ambassador/Campus Ambassador program seems to be partly based on the benefits derived from the structured workflow within the Fedora Ambassadors process. FAmSCo has an opportunity to reach out and collaborate to share knowledge about the process and at the same time incorporate suggestions which prepare the Ambassadors for higher achievements. More importantly, it would provide FAmSCo with a clearer way to measure its own success.

In all that spurred me to read up the discussion on Friedel’s blog as well as the i18n list. All said it is an interesting one and something which the teams and communities participating in i18n/l10n should provide feedback upon. It also fits into the current model of defining the ‘supported’ status of a language using application/package translation statistics. The discussion started by Friedel and Gil make sense. Especially so when looked into the context of community enthusiasm that I described earlier – the ability of the teams to sustain a level of translated strings and refine/review them over a period of time. Although there’s also the implied bit from Friedel’s blog about the utility of the statistics – in pure terms, what do the percentages mean and indicate ?

While reductionism in areas of re-defining supported status based on a set of packages being localized would work in the short term, a much deeper re-thinking needs to be in place for a longer run. Developers are the ones who create the applications, the end-users consume those applications. In between these two groups are the translation communities who tend to look at the content to translate – they look at strings. Thus there needs to exist a system or, method to enable the translators/localizers to look at strings that must be translated in order to provide a clean homogenous experience to the user of a localized desktop. This is opposite of the current method of looking at it from the level of an application/package. This blog provides one way of doing this. Looking at strings inside of packages that are required to be translated and then doing it across a set of packages aimed at a released and thereafter building on the Translation Memory created to re-use it for translation suggestions offered to translators would be a good means to provide an ability to be “agile” when localization is underway.

Being nimble would also allow the teams to quickly build the translations and check against tests (which need to be written, maintained and evolved) with the aim of improving translation quality. In short, there is a need for an additional layer of software between the Translation Management System and the translators themselves that parses the meta-information associated with strings and present them in a way for translation that can provide an optimal quality of the localized interface. Add to this the ability of the system to build and show the application also provides the advantage of translation review (remember that there is always a high chance that English strings can be misinterpreted while translating) and, checking whether the quantum of translation provides an usable experience. Availability of agility via tooling allows iterative runs of translation sprints over a set of strings. While this may be contrary to the way of how teams currently work, it would provide a better way of handling translations even when string freezes are requested to be broken – it would be another sprint with a sign-off via the review tool.

Excited to be in India, he concedes that community interest here is still on the lower side. Setting this straight is particularly important when it comes to GNOME localisation. “Localisation is a huge challenge here, mainly because there are so many languages, and also because of the way the alphabet font is linked. This is where Free software is critical, because smaller the user base, lesser the chances proprietary firms will take this up.” We count on enthusiastic developers, who are proud of their language and want to preserve it in the digital realm, Mr. Cameron adds. In fact, he points out there are “big business opportunities”, domestic and international, for those who commit themselves to such projects.

Brian mentions about community interest in localization being less. On the face of it, this appears to be a conclusion derived from looking at number of participants in the language communities. The way I’ve learnt to look at localization is to try and see the communities and the efforts which sustain. Localization is a steady and incremental process. The communities which take the time and make the effort to reach and maintain their place in and around the “supported” percentage for the individual Indic languages are the ones doing great work.

 
With each release of GNOME there is an obvious increase in the number of strings up for translation. I don’t have the exact statistics to support this fact but I guess a trend-line generated from the total number of strings available in each release super-imposed over the trend-line for the ‘supported percentage’ figure would see an increase with each release. I’m sure someone actually has this data. This basically means that within a short period of ~4 months (factor in the code freeze and string freeze etc), which may or may not also overlap with other project releases, the localization teams end up completing their existing release work, review pending modules and polish up translation consistency ensuring that with each release of the desktop there is a step towards making it more user-friendly.

That’s why localization is a big challenge. Not because of the number of languages and certainly not because of the “way the alphabet font is linked”. For what it is worth, the latter bit is more in the realms of internationalization and there are efforts at multiple levels to ensure that the remaining few outstanding issues get fixed.

This brings us to a small gripe I’ve had about a lot of Free and Open Source Software projects who take their L10n communities and participants for granted. I’ve rarely seen a project board reach out and talk with the participants to figure out what can be done to make things better. For example, would a community doing L10n do more awesome work if they were funded for a 2 day translation sprint ? Do the language communities have specific requirements on the translation and content infrastructure or, the translation workflow ? Have these issues been brought up in Technical Board meetings ? GNOME isn’t the only one which repeatedly fails to do this transparently, but it is among the highly visible FOSS projects which seems to assume that it is an obligation of its volunteer contributors to keep the statistics ticking.

Without further delay, here’s my wish-list for FAmSCo

• Specifically put forth a set of goals that the elected FAmSCo would work on and attach data points to it. The candidates may be had individual goals during the election phase but once elected there requires to be a cadence, a coherence. Currently, a trend I notice is an enhanced level of planning activity but not a corresponding set of performance tasks.
• Regular availability of the FAmSCo report – a cursory reading of the list archives say that this is an issue on which the ball gets dropped fairly often. The report is an invaluable way of presenting a narrative to the Fedora community at large about the functioning and changes being brought about by the FAmSCo
• Focus on regions where there aren’t enough Ambassador strength. The last time I checked there were wide swathes of the world where there aren’t enough Ambassadors yet. Reaching out to those there are and working out a step-wise plan to see how participation in and contribution to the project can be improved is a reasonably high priority item. And, solving this issue does not necessarily mean throwing money at the problem. While funds do help, at many levels it is a cop-out approach that releases one from the need to understand situations and begin conversations.
• Use the ‘slow’ time between releases a bit more judiciously. There has always been a small period of around one and a half to two months between two sets of Fedora releases when the activities within the Ambassadors communities taper down. This is partly seasonal and cyclic and partly a natural outcome of events – the initial days of a GA and, the last days that ramp up to a GA (with Regional IRC meetings etc) are the ones of hectic activity. Planning to use this window during each release to work on a set of activities that can help the Ambassadors introspect eg. Event Participation Retrospective would go a long way in making better use of time.
• Work towards converting the various FAQs into online courses/quizzes. By making them more engaging to participate in, it would probably work out better for Ambassadors who are freshly minted as well as for existing folks who need to refresh their readings. This is going to be a huge task even if it is properly scoped out. However, this will also ensure a closer collaboration within the various *SCo teams. And, potentially open up the project to a different set of contributors too.
• Organize and participate in *SCo meetings together with the Board.
• Figure out a way to get an Event Calendar similar to what LWN maintains. There has been much hand wringing and hand waving with the “wait for Fedora Insight/wait for Zarafa” coming along. The need for a calendar is driven by a very specific agenda – visibility of Fedora presence and, being able to see the proposed-vs-attended set of events. As the community grows across the globe and smaller and more often niche events require Fedora presence, the need to visually narrate the presence would create much enthusiasm.

To me a mentor is a “trusted counselor who serves as a teacher” and, mentoring or, mentorship is a personal developmental relationship in which a more experienced or more knowledgeable person helps a less experienced or less knowledgeable person (this is from the Wikipedia article which I’d recommend as a reading material).

Why would Ambassadors need a mentor anyway ? There are two answers. The simple and cop-out answer is that “everyone does”. The more complex and somewhat thought provoking answer drove the then FAmSCo folks to think through this issue. And that is because the Fedora Project puts the Ambassadors squarely in a public facing role. Over a period of time the profile of fine folks who stood up and signed-up for an Ambassador role varied. With the complexity and depth of issues that the project brings forth and, the need to always “be excellent” resonating through every activity within the project, it was a good idea to request some of the older/wiser/experienced heads to spend some time coaching the newer ranks. At no point in time was this responsibility thrust down to unwilling hands and, yet at the same time, these groups of mentors spent an inordinate amount of time ensuring that as the number of Ambassadors increased, time and effort was invested in maintaining to the high standards.

Additionally, FAmSCo has made it quite clear that it is agreeable to looking at newer mentors and, which is why there is a reasonably clear path available to any Ambassador who wishes to work with a current mentor and, thus be peer reviewed and accepted as a mentor. Having a group of one’s peers reviewing one’s performance and skills, especially soft skills is indeed a daunting experience. However, each of the newer mentors have been excellent Ambassadors and would eventually become wonderful coaches as well. In that context I somewhat like Christoph’s response. And, while the process might seem to be very “secretive” to few (it isn’t if you check the workflow), it does work because of the formal workflow that it has. Including the fact that discussions about new mentors have a section where the contributions of the Ambassador are discussed and the mentor peers provide their comments.

I don’t see a reason to keep a list of mentors-in-waiting. And, I certainly disagree with the disingenuous hint that being a ‘mentor’ is an honor or, a special title (do the mentors get a special button ? :)).

Mentoring, in my book, is a responsibility and it pleases me to see the Ambassadors who take time and make effort to coach new Ambassadors and also take time to select new mentors thus helping the project recognizing talent and appreciating contributions. Everyone can, and should, help the other person find their feet within the project and encourage contributions. Coupling this facet of a FOSS project with the idea that ‘mentor’ is a title is not only plain wrong now but wrong forever. And saying that someone who volunteers to spend time and effort to coach and help another person become a better contributor doesn’t possess any special skills (what skills are special anyway ?) is also being facile. I could draw analogies from various everyday situations at home where the “this role doesn’t require special skills” would lead to volatile situations, but you understand what I am talking about.

It is not in the special skills. It is in the special person.