Don't Say Geek! Say Syntux!

First let me give you a brief background of the current Arabic translation status, We have 167 contributor, 266742 untranslated string which make %64.72, 8847 strings that needs review.

I’m putting the following assumptions to build sort of road-map, one crucial way to way to boost the translation process is to get more contributors (I’ll talk about how we can double the number later), lets say we can double our contributors 334 lets assume that 300 of them will translate 30 strings a day and others will review the translation that makes 9000 translated string a day on the other side each reviewer will review 60 string a day which should be around 2000 reviewed string a day.

Having a 300 contributor translating to translate 266742 string would take 30 days to push our status 100% translated (which is kind of a dream) in the same month we will have 60000 string reviewed with 206742 strings that needs a review and by the way I’m putting the worst case scenario here which is we have to review all of translated strings and later if we were able to keep the same spirit we will have all translation reviewed within 103 days.

Of course we still have to find a way to export our translation to the upstream and hopefully make this automated in a way similar to Upstream bugs linkage.

Now, How to get more contributors?
People would do things for free if they have passion for it, if they need it, if it’s fun doing it and finally if they are making some money out of it.

Passion can be achieved by advocacy and encouraging new blood to contribute as translators, explaining why it’s important, the light-weight technical side of translation too and of course explaining how translating applications and documentations would help in spreading FLOSS.

Needing it and I wonder who don’t need to use an app or read a documentation in his native language, although most technical people tend to prefer English regardless of their native language but what about the community? they will definitely need at least the basic documentation that is enough for them to get started.

The fun part, if you watched Human Computation you would understand what I’m talking about, people spend lots of time online for fun and we definitely can make something that is fun and useful at the same time it could be via online translation game where people compete for points, scores or karma. someone might say but translation apps and documents is different which is true but we still have a room of doing something that is fun and useful at the same time but of course this would need loads of resources.

The money part, currently we’re discussing a sponsored translation campaign to boost the process and we already got some promises to get some cash from Jordanian companies that benefits from FLOSS however this wont be enough because if we want to pay $0.05 per string then we would need around 13,000 not to mention that we also have to pay for reviewers also payment processing fees which is still feasible if we got enough cash and if we can guarantee that sponsoring a translation wouldn’t introduce licensing issue.

Finally, no single approach can solve the problem but maybe all together can make a change and thinking of it again, passion, fun and needing it are the most feasible approaches.

Tags: worst case scenario, translation status, arabic translation, native language, new blood, documentations, floss, road map, linkage, contributor, assumptions, advocacy, bugs, passion, spirit, money, ubuntu, translation

Ben Chelf, Coverity wrote article titled Avoiding the most common software development goofs – Embedded.com
I will excerpt few paragraph of his article which I can’t agree anymore on it

If it’s clear to everyone that software defects are an expensive problems (and we assume that it is), why do developers make mistakes? Or rather, why do they make as many mistakes as they do to the point where NIST performs studies and shows that it is costing businesses sixty billion dollars a year? Based on our experience in developing software as well as interacting with thousands of software developers and seeing the types of bugs that come out of the software development process, we view the following as the top reasons developers make mistakes.

Ignorance. The reader might think from this header that we are taking a shot at the educational system that trains our software developers, but that is not the thrust of this argument. Developers are ignorant of the systems that they develop. A single developer can keep thousands, maybe even tens of thousands of lines of code in his or her head for the purpose of perfectly understanding how different pieces of the code interact.

However, today’s systems are in the hundreds of thousands, if not millions or tens of millions of lines of code. A single developer working on that type of system will be calling functions or methods of which they are quite ignorant. The pieces of the code that he is forced to interact with may have been written years ago by someone who is no longer available to explain their intent or nuance. So the developer does his best, quickly reading though the implementation or the comments (potentially incorrect!) provided when he needs to interact with another piece of the system. And this leads to errors.

Stress. We mentioned above that the developer does his best to “quickly” read through the implementation of a piece of code that he must interact with. If you are a developer, you probably didn’t think twice about the phrasing of that sentence (nor did we when writing it) because that is the reality of any software development process. Managers put pressure on developers to generate code quickly ” deadlines come fast and this leads to hasty coding and that leads to mistakes. Often these mistakes are not necessarily in the most common case of the code (since that is well tested), but on edge cases. When time is of the essence and developers are stressed, the parts of the code less traversed suffer. Yet these defects can be just as costly as mainstream bugs.

Boredom. Not all coding is rocket science. In fact, a good number of coding projects, once the design is complete, would be classified by most developers as “boring.” Of course, if a developer is bored, he is much less likely to produce good code than if he is excited about his work.

Pounding out those last few cases in a switch statement when the first few took dozens of minutes can be just mind-numbing enough to switch off the brain and make the simplest of mistakes. Boredom also leads to shortcuts ” if you are bored with any given task, you are probably looking for ways to eliminate your boredom as quickly as possible. And unfortunately, a shortcut in coding often translates to a defect in the code.

Human Frailties. Certainly the above points play into this last point about the very nature of human beings. Humans are creative and intelligent and able to solve difficult problems through reason. However, we are not robots. We are not so good at repeating the exact same operation thousands of times without some variance. If you doubt this, pull out a piece of paper and sign your name ten times.

Signing your name is probably something you’ve done thousands of times in your life, yet each time is a little different. This variance means that even if a developer understood every interface in a system perfectly, had all the time in the world, and were programming the most interesting project computer science has ever known, he would still make a mistake in the translation from the design in his head to the code that he writes. That is just a fact of life.

What I can say ? a very good analysis of reasons that lead to mistakes in developers life…

Tags: software development process, coverity, chelf, software defects, software developers, common software, developing software, educational system, nuance, billion dollars, thrust, hundreds of thousands, excerpt, tens of thousands, paragraph, bugs, implementation, stress