Open Advice/My Project Taught Me how to Grow Up

My Project Taught Me how to Grow Up

by Runa Bhattacharjee

in: Open Advice

This text is available under the CC-BY-SA license. (see also: Open Advice/Info)

Contents 1 Introduction 2 How it all began 3 How it was done 4 What mattered 5 How it made me grow up 6 What I should have known 7 Conclusion 8 about the author

Introduction

Burning the midnight oil has been a favorite form of rebellion by young people all over the world. Whether to read a book with a torchlight under the covers or to watch late night TV reruns or (amongst other things) to hang around on an IRC channel and tinkering around with an itchy problem with a favorite open source project.

How it all began

That is how it all began for me. Let me first write a bit about myself. When I got introduced to the local Linux Users Group in my city, I was in between jobs and studying for a masters degree. Very soon I was a contributor to a few localization projects and started translating (mostly) desktop interfaces. We used a few customized editors with integrated writing methods and fonts. The rendering engines had not matured well enough to display the script with zero errors on the interfaces, nonetheless we kept on translating. My focus was on the workflow that I had created for myself. I used to get the translatable content from the folks who knew how things work, translate it as best as I could, add in the comments to help the reviewers understand how I comprehended the text, filled in the necessary information for copyright and credits and sent them back to the coordinators.

How it was done

It was mostly a simple way of doing things. But most importantly it was my independent way of doing things. I took my own time to schedule when I would work on the translations. These would then be reviewed and returned to me for changes. Again, I would schedule them for completion as per how I could squeeze out some time from all the studying and other work that I was doing. When I did get down to work, I would sit through 9-10 straight hours mostly into the wee hours of the morning, feeling a high of accomplishment until the next assignments came through.

What mattered

What I did not know was that I played a significant part in the larger scheme of things. Namely, release schedules. So, when I completed my 2 cents of the task and sent them over, I did not factor in a situation where they could be rendered useless because they were too late for the current release and too early for the next release (which would invariably contain a lot of changes that would require a rework). Besides these, I was oblivious to the fact how it all mattered to the entire release process – integration, packaging, interface testing, bug filing, resolution.

How it made me grow up

All these changed drastically when I moved into a more professional role. So suddenly I was doing the same thing but in a more structured order. I learned that the cavalier road-rolling that I had been used to, was not scalable when one had to juggle through 2-3 release schedules. It had to be meticulously planned to map with the project roadmaps. While working on translating a desktop interface, one had to check what the translation schedule was for the main project. The projected date to start working would be right after when all the original interface messages had been frozen. Translators could then work unhindered until the translation deadline, after which they would be marked as stable in the main repositories and eventually packages would be build. Along with these schedules, a couple of operating system distributions would align their schedules as well. So the translators had the additional responsibility of making sure that the pre-release versions of the operating system that would be carrying the desktop, went through with some bits of testing to ensure that the translations made sense on the interface and did not contain errors.

What I should have known

The transition was not easy. Suddenly there was a flood of information that I had to deal with and additional chores that I had to perform. From being a hobby and more importantly a stress-buster, suddenly it was serious business. Thinking in retrospect, I can say that it probably helped me understand the entire process because I had to learn it from the ground up. And armed with that knowledge I can analyze situations with a better understanding of all the effective facets. At the time when I started working on the Open Source project(s) of my interest, there were much fewer professionals who worked full time in this domain. Most of the volunteer contributors held day jobs elsewhere and saw these projects as a way to nurture the creative juices that had dried up in their routine tasks. So a number of newcomers were never mentored about how to plan out their projects professionally. They grew to be wonderfully skilled in what they were doing and eventually figured out how they would like to balance their work with the rest of the things they were doing.

Conclusion

These days I mentor newcomers and one of the first things that I let them know is how and in which part of the project they matter. Crafting an individual style of work is essential as it allows a person a comfortable space to work in, but an understanding of the organized structure that is affected by their work imbibes the discipline that is required to hold in check chances of arbitrary caprice.

about the author

For the past 10 years, Runa Bhattacharjee has been translating and working on localizing numerous Open Source projects - ranging from Desktop interfaces to Operating System tools and lots of things in between. She strongly believes that upstream repositories are the best places to submit any form of changes. She also holds a professional portfolio specializing in Localization, at Red Hat. Runa translates and maintains translations for Bengali (Indian version), but is always happy to help anyone wanting to get started with localization.