I happened to re-read this fine piece of penmanship today. And in the light of recent incidents figured that it would not be out of place to muse about a few small steps that can get localization contributions integrated with existing communities.

Some preliminary definitions should set the context for the post:

• Upstream: the catch-all term for the ultimate source of the project – a place where the core contributors put their work into the version control infrastructure and other related bits like bugzilla/issuezilla etc come together to provide some ‘dashboard’ view of the project. In the context of localization, it usually points to projects like GNOME, KDE, Firefox etc whereas distributions like Fedora, Debian etc are considered ‘downstream’
• Communities: existing special groups, generally organized around locales who handle the translations/localization of content for the upstream and downstream projects
• Contributor: in this particular instance it would be the person who has demonstrated interest in contributing localization work for the particular language community

Now comes the short and sweet list of things ToDo:

1. Discuss and declare your intent to contribute in a public forum – the teams working on l10n are pressed for time since they have to juggle around the string freeze deadlines for a variety of projects. And, since most teams / language communities are made up of a small number of people, there exists a tacit understanding towards tasking. Discussing the intent to contribute in any of the public forums makes it easy for the members to allocate tasks to you
2. Study the community – most of the members for the language community have been working together in tandem for a long time. Thus, they have a well oiled mechanism to handle the deadlines of the project. Studying how the members interact over mailing lists and / or IRC would provide pointers as to what could be construed as constructive and what is ‘being smug’
3. Contribute work incrementally – it is always better to start off with small chunks of localization content. That allows the members to review the work and provide pointers in addition to that being a ice-breaker
4. Acknowledge reviews – the language teams have in-place language consistency standards, processes and guidelines. Acknowledging the reviews and incorporating elements from such guidelines makes for better working relationship
5. Review work before submission – this shows that you care about the quality of your work and take pride in being a part of the team. The small bits that are required to be reviewed are generally constant and can be converted to a check-list
6. Update your work status – that helps the ‘leader’ of the language team to assess progress of work and also put in place small tweaks towards meeting deadlines and goals
7. Get legal clarity – if your employer / employment contract requires you to use a particular ID or provide some extra credit, please ensure that this is discussed upfront with the team and all issues are discussed towards mutually agreed upon clarity
8. Learn the basics – take time to learn the basics of
• Version Control Systems of the upstream project(s) you will be contributing to
• Usage of IRC
• Usage of mailing lists
9. Expect and accept rejection – there may be multiple reasons as to why your intent to contribute to a particular project may be rejected. And instead, you could be pointed to some other project that the language team is also working on and asked to contribute. There could be number of reasons for that. Expect such events and accept them.

Being a good contributor begins with being a good citizen (a phrase I borrowed from Pradeepto). And, that starts off with small steps.

[Thanks to Richard W Jones for his initial page]

These days I am generally averse to government sponsorship of (aka investment in) Open Source, especially if the government in question happens to be the Government of India.

I had earlier blogged about BOSSLinux and in recent times I tend to abhor politically motivated over-the-wall Open Source on taxpayer money. For example, take a look at this cache.This is the collection of over-the-wall translations of GNOME files. The fun part is that language teams exist for a significant number of the languages that are part of the collection. And yet, the files have the curious header: “Language-Team: Bangla (INDIA) (info.gist@cdac.in) \n” for bn_IN example. I don’t recall anyone contacting the group working on bn_IN for this and coordinating the work in that community. The discussion over the past few days on #indlinux also shows that the ml_IN community has not been contacted, neither the or_IN.

The reason why C-DAC desires to undertake this nonsense is fairly clear. Currying political favor with the incumbents at ministries, re-inventing already undertaken tasks is something that the stellar agency is becoming excellent at in recent times. Language computing in India is a big ticket item. Various e-Governance projects are looking towards reaching out to various language communities for greater outreach. There is work going on in standardization and so it is a good time to start acting silly. For a few languages that don’t have all the Unicode issues resolved, there seem to exist translations. Amazing is what it can be called. Why would working with the communities in the form of collaborating be something that is beyond the intelligent folks at C-DAC is what bothers me. These folks have been around for a while ie. they are not newbies starting up a project, they are smart. So, if they are upto such stupidity, there has to be a reason to this madness. Trying to fork translation communities instead of collaborating is a sad way to move forward.

Moving on, let’s take another piece of oddity. Baishakhi Linux which says:

Society for Natural Language Technology Research (SNLTR) developed Baishakhi Linux 1.0 (pdf link) in collaboration with MAT3 Impex and IIT Kharagpur. This is a free Bangla Linux that has been built over Ubuntu 8.04 distribution. All computer related decision making and office activities, such as document writing, preparing presentations, web browsing, sending and receiving emails as well as spreadsheet calculations can be carried out in Bangla using this distribution. All Bangla compound words can be viewed and written in Baishakhi Linux, and this special feature distinguishes it from the other localized Linux distributions. Even in spreadsheet application (an office suite for calculation) all types of mathematical calculations (addition, subtraction, multiplication, division etc.) can be done in Bangla including fraction number, which is also a unique feature of this distribution.

The bits that are termed as ‘salient features’ have not been contributed upstream. What a waste.

ps: If this bug gets closure, a lot of issues would be resolved.

The Durgapur Linux Users Group or dgplug started around 5 years back when Kushal and few of his friends got together with the usual aim of creating a group of users of Free and Open Source Software. It wasn’t an unusual LUG. At that point in time there were a number of such groups forming all over the country. Kushal and his friends took the well beaten path of approaching schools and colleges, helping set up install fests, guiding a few students in their projects. Sometime around the beginning of 2006, they registered #dgplug on Freenode. Even this was a known way of going forward. A lot of LUGs in India have their own (and perhaps registered) IRC channels. However, things did change from here onwards.

As per the current system of education, students of engineering (especially Computer Science and Information Technology) have to undertake a mandatory period of summer training. While the regulation was with all good intent, the side effect has been the exploding growth of ‘infotech’ houses which offer such training to the students at a cost. The current rate in West Bengal is around 3000 – 6000 INR per student. The students don’t really ‘learn’ anything at such places. They pay up the fees, meet with fellow students and at the end of the duration of the training obtain a ‘certificate’.

So, the #dgplug folks, largely led by Kushal figured out that a far better approach towards training could be undertaken if the training went ‘virtual’. Thus, IRC was chosen as the medium of communication and a ‘Summer Training’ curriculum was drawn up. Blogs and word-of-mouth was used to let students know about this. Not surprisingly, a large number of students signed-up to be part of this somewhat experimental training program. Experimental because, although a few FOSS projects do have regular classrooms, they are mostly focussed on specifics of the project and don’t blend with the curricula that the students would be familiar with. #dgplug also signed up a fairly impressive cast of mentors who could guide the proteges into the world of FOSS and especially coach them about how to become involved with various communities and sub-cultures that exist.

Since the mentors are from across various timezones, keeping the classroom virtual has worked out really well for both the protege students and #dgplug. The medium of IRC also allows transcripts or logs of the meetings to be archived for easy reading offline. The method is elegant and simple. The mentors pick up the topic and hold a classroom. They also provide homework to the students. The content of the homework is not something that can be copied from existing documentation, but requires some amount of original thinking. After the students learned about version control, the answers for the homework went into the training repository of #dgplug at http://dgplug.org/training/

At the end of the training, the students are expected to undertake a project for an existing FOSS community and submit it to the respective upstream. Pretty neat.

So, all this ends up achieving something significant. While this is a small beginning with a group of students and mentors, it does prove that IRC can be used to coach and mentor new contributors. And, it also provides some empirical evidence that coaching in FOSS need not be outside of the existing academic curricula. It can start from within and slowly gather momentum to bring about substantial changes. Even earlier, small study-group like environments to teach GNU/Linux have met with a reasonable amount of success viz. GLT-Madhyamgram, having a lot more training on #dgplug from mentors willing to contribute a small portion of their time would lead to impressive results.

Durgapur may be a small speck on the map of the country, the IRC channel #dgplug and the screencast channel surely isn’t. Not with a number of GSoC candidates from the region. And certainly not with the amount of activities that it conducts.

Update: If you are interested in becoming a mentor to a new batch of students and guide them towards contributing to FOSS, please join #dgplug on Freenode.