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.
I want to respond very quickly to a few things:
– Once a month check-ins on goals seems perfectly reasonable to me. We want to see progress, not necessarily see them reached. Increasing frequency of feedback is a good thing.
– I agree that the council should have its own goals, and I think it should periodically report on its own progress to the community.
– I’ve learned that we need to spend a lot more time focusing on how to improve our people (in this case, team/project leads) and a lot less time talking about how to get rid of them.
– It’s clear that we’ll need to come up with ways to easily generate and process data relating to these goals. If done efficiently, tracking progress should not be difficult, and an in-depth meeting might happen once every 3 months.