Negative feedback

Here’s the second part of my comments on Donnie’s now famous post. Negative feedback is, in electronics, what keeps an operational amplifier stable around an operating point and improves its performance by a great deal. In other words, it keeps it focused on a target and makes it more efficient. This is exactly what I’m going to discuss below, and it illustrates very well that negative feedback is often a positive thing.

Each team and project should have goals. A good goal is SMART (Specific, Measurable, Attainable, Relevant, and Time-bound). That means “Maintain foo packages” is a poor goal, because you cannot answer it in a quantitative way and it has no time limit.

Yes, definitely. Not having clearly defined goals is something that has been hurting Gentoo for as far as I can remember. And that’s way too long. Without them you have to rely on randomness to progress, and good real world randomness has a mean value of zero. Goals enable developers to be orders of magnitude more efficient. The trick is choosing them and balancing the difficulty properly but we’ll get there. The real issue in my opinion is having most of our developers agree to play the game. Let’s be realistic, we won’t be able to convince everybody. We may even not be able to convince a majority at first, but if a smaller group can show others it works it’s already a good first step. And it will work, I have absolutely no doubt about that.

Progress toward goals should be checked once a month by the team lead and reported to the project lead (or to the council, if no project lead exists).

This is a detail, but I’m not sure once a month is realistic. Let’s not forget that many of our developers are students and they have exams and vacations a few times a year. When they get older they discover booze and the opposite sex (or the other way around but I myself started with booze), and before they know it they’re cloning themselves. Which makes them even more busy. It’s not unusual for developers to work in bursts of a few months and then go away for a few months. It’s a matter of them finding the necessary time and motivation. And although there’s a lot we could do to motivate them better or more, we can’t do anything about the amount of time they nicely agree to give away to Gentoo. In a small team, two or even one temporarily inactive developer(s) can have a massive impact on the amount of work done. Setting a longer period like 2 or 3 months would allow to average out statistical irregularities due to developers having a real life. It may have drawbacks though, and we’ll need to discuss it.

What is less of a detail is who does the council report to. The usual answer is that they are elected and you can always vote them out at the next elections, but it’s not really the same as reporting. Will developers and users be happy with them having free reigns for one full term without having to report on their own progress? There have been requests in the past for a way to disband a poorly working council before the end of its term. In this case we’ll need our council to have measurable goals too. Honestly, if all projects have their performance measured it seems only fair that the council’s performance is also watched. This would at least create a good basis for discussions during elections. By the way, does disbanding a council in the middle of its term really serve Gentoo? Whatever we decide we need it to be properly designed and written in order to avoid repeating the “slacking council” fiasco of a few months ago.

And what about project leads? Today there is no legitimate way to remove a lead who’s not doing his/her job properly. Apart from a council- or devrel-mandated putsch which may not be well perceived even if it’s well deserved. If we want to be able to do this, and I strongly believe we need it, we must give ourselves the means to do it. Without endless discussions on the why and the how, that is. Somebody, somewhere, proposed a slight modification to our organization which enables this, but that’s a topic for another discussion.

Finally, will the council have the manpower to process this much data about project and team performance? Before the last council meeting I caught a conversation between two council members. One was telling the other that the situation today was that basically we only have two operative council members. And one of them became a father just recently, and the other is often very busy at work and admitted he’s losing interest in council stuff. He was certainly exaggerating, but as we say in French there’s no smoke without a fire. Let’s face it, we need to reduce their workload, not increase it. Or refocus it. Or something. We’ll talk about this too someday.

Wanted: top-notch developers only, or not

Donnie recently posted this which made some noise. Before we go any further I’d like to say that I liked it a lot and found it very interesting although I’m going to sound very critical about it. Exploring this kind of ideas will benefit us, whether we use them in the end or not. At least if we don’t we’ll know why we believe they’re not appropriate to our own little world.

I’ll have to split my comments in a few different posts because I was told the previous one was too long. Sigh. Let’s all thank television and its commercial breaks for unlearning our kids to focus more than a few minutes at a time.

Keeping in mind the Pareto principle (20% of the effort produces 80% of the results), I’ve come up with some ideas. The core of these ideas is creating a development community composed only of top-notch contributors […].

Here I’d like to warn the reader who’s not used to corporate bullshit (tell your mommy that in this context it’s not a bad word but a technical term). Donnie uses the Pareto principle in the good way: as a clue to what the problem could be or as a lead to an idea. However, general principles like this one were made up by bright minds and are abused by corporate robots everyday. It’s so easy to derive, from such theories with a certain amount of undeniable truth, a pretty looking analysis that doesn’t fly or a practical application that smells funny. It’s so comfortable to hide behind numbers and tell upstream (the boss) “Hey it’s not me, it’s the numbers”. When you use such tools blindly and push them too far you may end up crashing into a wall. And the wall in Donnie’s case was top-notch.

It’s true that we some of us I tend to procrastinate a lot and then do the real work in short bursts. It’s also true that my neighbors’ house popped up from the ground in a few days and that months after they’re still working on who-knows-what inside. And it’s also true that there’s a small group only of Gentoo developers who seems to be doing most of the work. Now, do we know how much procrastination participates to creativity? Don’t you know how long it takes to do the wiring, plumbing, painting etc… compared to just building the walls? And do we even have a vague idea of how much so called slackers contribute to the Gentoo ecosystem?

I don’t have exact numbers but it seems to me that the 20% of top-notch developers are a fluctuating population constantly drawn from the 80% tank of slackers. And that if we got rid of the 80% we’d have trouble maintaining the number of top-notch developers. And that’s just the tip of the iceberg. Top-notch developers won’t do chores. Or not for long. Top-notch developers often can’t be bothered to answer users. Top-notch developers don’t always behave well so it’s a good idea to dilute them. Top-notch developers may not want to handle obscure package herds. Oh, and do top-notch developers write a lot of documentation? I could go on like this forever.

By the way, I’m not meaning we should keep the bad apples. Some of you may know which side I’m usually on when devrel needs to vote on retiring annoying developers. For those who don’t, let’s just say I don’t have a high tolerance for counter-productive behaviors. But between bad apples and top-notch developers there’s a lot of room that I find very comfortable.

Here’s another provoking thought. One could argue that if the 20% were that top-notch, they would naturally fight their way up to 30%, 40%, etc… If this population is so fit for its environment and purpose then it surely has this very basic evolutionary skill. If not then they’re not top-notch in my book.

So you think you’re a top-notch developer? Try and make me become one and we’ll know for sure.

Moving in. And out.

So that’s it. That thing kids have been doing for years, I’m doing it too. It can only mean I’ll be a bit less of a dinosaur from now on.

I’ve resisted blogging for years thinking nobody really reads blogs. Except for the really interesting ones, for sure, and mine couldn’t possibly be interesting. However, the main reason I stayed a non-blogger for so long is certainly because everybody else was doing it. And just recently I thought I had better get into this blogging thing before my mother-in-law does it. Can you imagine that? Scary. I can’t afford to take that risk.

This is your typical mostly useless “Hello World” post. Mostly only because you usually post it to make sure everything works, but other than that it’s of no interest. So I’ll try making this somewhat less useless by giving an update on why I’ve been slacking for so long.

Some of you may know that I’ve been in the process of moving to the US. Again. Of all times it had to be now, talk about bad timing. It was supposed to happen quite some time ago but things got in the way. Things like some real-life work project taking more time than anticipated and requiring me to stay in Europe. And other things like some very recent mortgage rules in the US which make it virtually impossible for a foreigner to buy a house. On top of that the housing market in Boulder hasn’t fallen that much, if at all. Sure, things are moving slower but prices are still up there. A change of plans was needed.

So we made a decision. The Big Boss (a.k.a. The Wife) and the two Tyrants will stay in our summer house in Olympia, WA until the end of the school year because they can’t stay in France any longer. In the meantime I’ll have a lot of travelling to do for work so I may not be in the US that much anyway. Actually I may not be anywhere much. As soon as things settle down a bit I’ll be able to start looking at getting them a place in Boulder for the next school year.

At that point I’ll get a decent internet connection and I can resume working on Gentoo. My main task being recruiting, I need to spend hours on irc for the reviews, interacting with recruits in order to complement their mentoring, and threatening people to kill their cat if they don’t join us as Gentoo developers. Yes, now you know how we recruit: blackmail. Try it, it works. Anyway, not having a real place to live for a few months, I have to use pay-as-you-go HSDPA which costs 25 € for 6 hours. So I can’t idle on irc anymore. While I’m away Petteri is doing a fantastic job at keeping the recruiting pipeline at a not-too-shameful size. And he’s training two other recruiters which is excellent news. We’re finally getting some help after months of begging for volunteers. Training recruiters is a huge amount of work but it’s the best investment he can make of his time.

And there’s the packages. I maintain the sci-electronics category alone or almost and it’s slowly but surely rotting. I bumped some packages and fixed a few bugs here and there and it’s more and more difficult. Without a decent internet connection I can’t follow up. Whoever you are, if there’s one bug you can fix there please do. Don’t think you need to be an electrical engineer to maintain these packages. I’m one and there are a few in there that I maintain that I don’t even have a vague idea of what they do. All I know is some people use them and file bugs. I can understand these users giving up on Gentoo and switching to Fedora where people like Chitlesh Goorah are doing an amazing job at providing users with a great set of tools for electronics.

Another package that deserves more attention is hplip. An awful lot of people use it and it’s a few bumps late already. The problem with this one is you need to be able to test not only printing but also scanning and faxing. The latter is the issue as fewer and fewer Officejets have fax capabilities nowadays. Mine does, but it’s in a container somewhere between Houston and Denver. Timo nicely offered to help on the ebuild, but he can only test printing. If you can test scanning and faxing and know your way around ebuilds I’d suggest you comment on the various hplip bugs to make yourself known. Fortunately I have simplified the ebuild in the two years I’ve been maintaining it, and as far as I know there are no major bugs.

Feel free to touch any of the packages that I maintain. Don’t feel like you have to add yourself to metadata but you’re welcome to do so if you want. And don’t be afraid to break anything, you can’t possibly break more things than I did.

Congratulations if you made it this far. Next I’ll discuss Donnie’s excellent post on improving Gentoo.