5 a day

What is 5-A-Day?
We, that means everybody, will do 5 bugs a day - every day. With only
five bugs that everybody looks at every day, we will cover a lot of ground.

What you can do? That's up to you, your interests and your abilities.
 - If you're a developer, you can help out reviewing patches and getting
them uploaded.
 - If you want to just confirm new bugs, you can do that.
 - If you have experience with a certain package and want to triage bugs
you can do that and forward them upstream if necessary.
 - If you know your way around Ubuntu quite well, you can help assign
bugs to the right package.

What you need to do to participate?
 - Do it! Follow the instructions on the 5-A-Day homepage
 - Spread the word by adding your 5 a day to your mailing list posts I have been trying my best to triage 5 bugs a day, but max I could do was 3. Hope I can try better in future.

the hackday

I am sure my colleagues should have published the same in their blogs, but I do it anyway. Since I joined here, each one have been working individually though I have done some pair programming with jace a couple of times.  But today was a special day. For the first time, 5 of us were working on a single project, each one playing a unique part. But still we found a lack of proper communication and collaboration between us that jace resolved to make us sit together in one room and work together. Suddenly we saw a lot of things fixing up and things moving faster towards completion. Still we have a night to go through, to test everything and make sure it just works. We ended up having a hackday, with 7 of us moving our systems into the discussion room. Sorry, I am not uploading any snaps of it but think kushal has done that.

the best ever recruitment call I have ever read

Hello. This is yet another recruitment notice, though one that will
hopefully not pass for being just Yet Another. I’m posting this to a
few lists. For those subscribed to them, I hope you don’t mind the
repeat posts. If you think this is worth forwarding elsewhere, please
do.

I represent a small team at Comat Technologies (www.comat.com). We’re
seven people, with two joining later this month, which will take us to
nine. We’re looking for a tenth person to round off our skills and
take us into double digit team size. Maybe even a eleventh and twelfth.

But before I describe the job, let me describe what we do.

Comat is a ten year old born-again startup that operates in rural
India. You’ve no doubt heard the rhetoric of the digital divide and
how it needs more attention. We operate in that space. We’re not a
charity. We’re a proper business that pays competitive salaries and
believes there’s a genuine opportunity that may not be easily
accessible, but is very real.

In real terms, what we do is setup and operate computer telecentres in
villages across the country. Our first project was in Karnataka, where
we operate the 800 telecentres that you’ve probably heard of as the
government’s Nemmadi project.

These telecentres are basically a shop on the main street of the main
village in each cluster of villages (aka a “hobli”) containing two
computers, a printer, scanner, webcam, UPS, satellite internet
connection, and a human operator who talks to customers. The services
offered include getting a copy of one’s land ownership certificate and
recharging a pre-paid mobile phone.

Does this sound exciting? Perhaps as much as the rundown neighbourhood
DTP shop where the fellow who once must have been a glorious computer
professional now appears a lowly typist, augmenting his income with a
Real Estate desk that finds you local Paying Guest accommodation? What
would you want to be doing in there?

Consider this: the average village that we operate in receives four
hours of power supply a day. The supply is often at 150V, far too low
to power a computer or charge a UPS battery. The place is also a good
four hours from the nearest urban centre, and given the state of roads
in much of the country, that’s four agonising hours for anyone who
must go attend a support call because the operator complained that his
web browser is saying “Page Not Loading” and he’s got a long queue of
agitated customers who are threatening a riot because that printer is
not producing the document that will determine their livelihood.

You, the hotshot Web 2.0 and assorted buzzword compliant web
developer, must produce an app that will keep that crowd happy. You’re
not going to get away by telling them that your JSON-spewing Ajax
application requires a low latency internet connection. You’re going
to have think this through very carefully.

If your family is from a village that you visit on vacation once a
year, you’ve probably fantasised having to explain to your
grandfather’s neighbour what Python is and why it’s not a snake, and
what the heck a programming language is if it’s not a snake.

What we’re offering you is a telecentre that is already in your
village (if that village is in Karnataka), where folks will directly
or indirectly use the code you write. That’s a guarantee.

The trick, and the challenge, is to do this in a manner that’s
applicable across the country. A field trip to one location that’s
reporting weird behaviour is probably an adventure. You’ll pack for a
day trip, leave early in the morning to avoid the rush, drive till the
road turns bad, grit and bear the next two hours to the location,
break for lunch, have a nice chat with the operator, take some
pictures of the neighbourhood, and maybe even figure out that his
problem is that his browser somehow got set to cache too aggressively.
Someone must have told him it was good strategy given the low quality
connection. Maybe you’ll make a new note for the helpdesk people to
check before they ask you go to have a look next time. And then it’ll
be evening and time for a ride back, shower, dinner and a good night’s
sleep. A day well spent.

But do this five times, and it no longer seems an adventure. You want
to write code, not be trapped in this debugging nightmare.

We’re not supporting five or fifty or 500 centres. We’re currently
close to a thousand operational centres, scaling up to six in the next
six months and aiming for ten thousand by the end of the year.
Operations on this scale require a wholly different thought process,
for both software development and support.

I’d like to tell you that our little team of seven does all this, that
we’re superhuman ninjas who write code so great, it never fails, who
oversee operations for thousands of centres, who uphold peace and
harmony everywhere, and still go home at 6 PM.

But you know better. An operation at this scale literally requires
thousands of people. There are all the telecentre operators, at least
one in each location, their supervisors, people who specialise in
various forms of support, people who talk to other people to introduce
new services, people who count even when they’re sleeping, and people
who think deeply about the larger purpose of all this.

We’re the little team in the middle of the operation that provides and
supports the technology everyone depends on, and that is constantly in
pursuit of greater automation to enable larger scale.

We bear a great deal of responsibility for such a small team and it
shows in the way we’re structured. We have no patience for
bureaucratic approvals and hierarchies. Everyone is their own manager
and must see their project through its entire life cycle. In return,
everyone gets to decide how they want to work, when they want to work,
and what they want to work with.

Since the company has an overall HR policy, we fit our team structure
within it. We recognise the notion of people working On Site (ie,
home) and offer compensatory leave if someone works through a holiday.

We meet once a day to catch up on what we’ve been up to and determine
if someone needs help or could do with the experience of another.
Actually, calling that a “meeting” makes that sound more formal than
it really is, because we also sit close to each other and talk
throughout the day (with the more discreet types using IM with the
chap three feet away).

We don’t follow any formal methodology as we’re making it up as we go
along. Two standard features so far are the daily stand up meeting and
two week iterations for the folks whose primary contribution is in
code. Our next iteration starts on Feb 18.

Several of us hang out together after work. We share hobbies and
intellectual pursuits, we blog, we organise events, we superpoke each
other on Facebook, and we go to conferences (even the un- variety) to
talk about our work. We do not de-bar the personal from the workplace.
We believe in taking personal pride in what we do.

We are, however, not superhuman or all knowing. We lack certain
crucial skills, and where we do have them, there are just too many
things to be done. It would be nice to actually go home at 6 PM every
day. It would help to be working with people who can round off our
skills. In particular:

* Python (but of course!)
* Ubuntu/Debian Linux admin (both servers and user desktops)
* Windows desktop admin (the uncomfortable reality of working in the
space we do)
* Windows/Linux network management (thousands of machines, remember?)
* Project management (people who know what a gantt chart is and why
it’s useful, or not)
* Process observation, documentation and automation (let’s see you
repeat that complicated setup again)
* Technical documentation (for interface with external entities)

Any combination of these skills is useful, interesting combinations
better. An advanced ability with at least one is needed.

If interested, send your resume to my work id (kiran dot j at comat
dot com) with a note on why you’re interested. Or if you’re just
curious and have a question or a comment, I’m ‘jace’ on
irc.freenode.net, usually in ##linux-india, and ‘jackerhack’ on most
IM networks. You could also call me during a reasonable hour. My phone
number is easy to find.

Note: Feel free to poke me (techno_freak @ irc.freenode.net) if you want to know more before you talk to jace, I can tell you how awesome it is to work in such a dynamic, responsible, proud team where every one is a manager of his own. We share a lot between us, even though we might work on entirely different projects or environments (yah, we have some windoze guys too). If you ask me what do you need to, I will reply “never say can’t do attitude” and just that.

fossconf chennai 2008

Chennai chapter of Indian Linux User Group had geared up for their new avatar as conference organizers. Their long standing stint of not conducting a conference of their own was going to end. The discussions were happening for months, new logos getting designed, new conference management system getting developed. NRCFOSS joined hands with ILUGC and finally Madras Institute of Technology, the premier and historical institution which created leading professionals and world famous technologists like Dr. Abdul Kalam, was selected as the venue.

The conference was focussed on being a platform for first time speakers to come out of their shell and get an experience of speaking in a FOSS conference. Their audience will be a blend of experienced FOSS community members, students and academicians. In addition to just talks, there was also demo stalls as usual. This time, in addition to usual demo stalls on various topics, we had student present their final year projects. This was an opportunity for them to interact people who were doing similar things in their professional life, thereby they could get the valued feedbacks from the community and improve their projects.

The lectures happened in the Lecture hall, while the demo was in Hanger I (where Carte Blanche used to happen every time). Various colleges who have been interacting with ILUGC and NRCFOSS had sent their students as volunteers, participants and delegates. The core volunteer team was formed by the enthusiastic MIT Computer Club students, the one who conduct Carte Blanche every year (supported by ILUGC).

We had around 109 talks spread over 3 days (actually 2 days) and 863 registered delegates, while the registration desk reports the total attendance was above 1500. The attendees were mostly students from colleges and a few from nearby schools, academic community from the participating colleges, a few from the industry and representatives of the community. There were around 10 physical volunteers from ILUGC and another half a dozen from NRCFOSS co-ordinating the entire conference.

The conference formally began at 1.00 PM on 1st February, 2008 and was formally closed with Brian’s talk at 2.00 PM on 3rd February. Though there were few talks without enough audience, the beginner level talks were running houseful. May be the speakers should consider the focussed audience group before selecting what they are going to speak on. Or, may be we had too many of new entrants getting enlightened about FOSS that they choose to stick with beginner talks. We will be careful next time when we accept talks.

Though there were initial glitches and confusions during the first session on Day 1, with a speaker going missing while the alloted room was filled with audience, we managed to straighten up things as soon as possible. We had lots to learn from this experience of conducting a FOSS conference, when the major audience was students pretty new to the topic. There was also some logistic issues due to miscommunication or lack of proper communication channels. But on a whole we managed to walk across the rope, from one end to another without falling down and bruising ourselves.

We had people from few other LUGs attending the conference and they were really surprised to know that the entire show was run and supported by the students, with the LUG just standing behind and giving them a shoulder when needed. They also appreciated the idea of displaying the student projects which were actually nothing but final year projects for their B.E. degree.

What I wish to do now is to join hands with some of my friends (if they like this idea), with the students themselves and help them have a hosting space where they can properly host their projects. This means they will have a version control system, a issue tracker and project management tool and a weblog for them to blog as they proceed with their development. A few, with whom I talked about this, were really interested with this idea and said they will help in this. Hope, I get a few more helping hearts from those who read this post

The fossconf chennai has ended and we are contented of performing to our best, and accept the mistakes we made, taking them as a good learning experience to improve ourselves next time. Thanks for those who supported us, who participated and those who have a shoulder and hand in making this happen

Monthly Update - January 2008

The new year has been busy, but not so really busy in terms of busy. Been quite involved at work, with a lot of things to do with my project on Login Control. Somehow managed to get things working, only a few bugs to fix and packaging to be done. On Ubuntu front, got my hands in Bug Triage for few weeks now. With Onkar’s help, managed to submit a patch for enigmail bug which seems like will not be accepted. Not having an internet connection at home is taking toll on my contribution plans, especially holding me off from trying out with packaging.

There remains a pending blog post which I promised to make, if my patch gets some attention. It’s about an introduction to fixing bugs, repackaging and submitting debdiff to close the bug. Now it looks like I have to go with the post without my patch actually getting accepted.

I will barely be at office during the February month, as I will be at fossconf Chennai in the first week, then go to Mumbai for a workshop at IIT-Bom and then again to Chennnai for my cousin’s marriage. Am talking at fossconf chennai tomorrow and again on Sunday, though I have not prepared anything for it yet. Have a dozen tasks in my personal ToDo for the trip, so I am not sure how long will I be able to hand out in fossconf. At least, can use this opportunity to meet my ILUG Chennai friends whom I have not met for months since I went to Bangalore. Probably the next few posts in my blog will be on fossconf chennai experiences.