I wrote a short note on the history/context behind the bn-IN/bn-BD decision and other things here If you’d like to comment/discuss, I’d prefer the G+ post than this blog.
The Wayback Machine reveals that 20May2004 was the first time it crawled http://planet-india.randomink.org/ It has been nine years of making friends, crowd-surfing, reading about stuff folks are up to, life hacks and so much more. There’s not much to say other than “keep writing!” I know of a number of folks who like what they read and help out by pointing out new feeds which need to be aggregated.
I was reading through two email threads on the dev l10n mailing list for Mozilla and wondered what it would take for the project to actually have a conversation with the language communities.
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.
It seems that I keep writing about the FAmSCo I was reading Joerg Simon’s post on the Membership statistics and wondered if the FAmSCo has considered the following aspects:
- 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.
My last blog post about a newspaper article turned into a comment stream about ‘supported status’ and ‘reducing translation’ and ‘redefinitions’.
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.
On the sidelines of the GNOME.Asia 2011 at Bangalore, an article in The Hindu “This one’s no gnome” was published. When Srinivasa Ragavan tweeted about it, I mentioned about the ill-formed comment
The paragraph of interest is here:
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.
I got myself one these. The D-Link DWA 125 Wireless N 150 USB Adapter. Turns out it doesn’t get detected/work on Fedora 14. Has anyone been able to get working on a similar distribution ? Or, is there a document that says what I should be trying to do ? I couldn’t seem to find one myself.
I write the Ambassadors Beat for FWN. And, it requires me to read the mailing list traffic on the ambassadors and famsco list with attention to detail. I had mentioned some concerns earlier but this is more of a wish-list. Especially so because I read the Board Goals and I notice that none of the goals have a measure-able data point attached with it (well, except perhaps the FUDCon in India one !).
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.
While reading through the mailing list archives I chanced across a new Mentoring Proposal for Fedora Ambassadors. The list has seen some discussion going on around the topic of “How to be a mentor” and, the current proposal is part of a thread about New Ambassador Mentors.
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.
A bit back I had posted a question to the advisory-board list – specifically asking whether there has been a process to understand how Steering Committees have made things better. While the thread petered out into nothingness, a recent announcement about the Community Working Group got me thinking again.
The initial question to the advisory-board was based on a scenario that the multiple domain-specific sub-committees work towards being excellent within the scope of their own deliverables but collectively don’t work together towards a greater purpose. More importantly, whether the work of the *SCo and the choices they make have proper communication both to their constituents and within The Fedora Project itself. Now with the announcement of the Fedora Community Working Group I have a set of queries that would perhaps require a bit of elaboration.
- what is the mandate of the newly formed group ? Are they empowered to ‘act’ or, is the charter limited to generating and submitting a proposal for consideration ?
- the “central point of contact” phrase is bit quirky. It doesn’t say as much as it is supposed to say – what does this actually entail ?
And then of course there is the mission
The long-term goal of the Community Working Group is to help to maintain a friendly and welcoming community, thereby ensuring the Fedora Project remains a great project enjoyed by all contributors and users
This is perfect as a long term goal. Across the year and across multiple specific Fedora lists there has been, I feel, instances of ‘stop energy‘ especially pointless and rambling ones (is there any other kind of stop energy ? I hear you ask, more on that later). If the CWG can sit down and straighten things out or even look into the frank admissions of burn-out it would perhaps be a good thing to have. Along with the stated charter of facilitating communications between the groups or even, doing post-release retrospectives (I’d rather love to see the various Steering Committees take the initiative in this – FAmSCo does a reasonably good job that needs to be appreciated) in order to plan for areas of improvement in processes. If the CWG can then obtain buy-in from the specific teams who can bring about the changes it would be wonderful to have.
The CWG is a good start. I’d perhaps like to see a bit more specific items that can be measured as success or failure of the CWG rather than goals well into the future.