I laid out part of a framework for improving Gentoo in my last post. As many of you kindly noted, I explained what I wanted to do but did a poor job of convincing you why it needs to happen. That’s what I’m going to begin doing in this post.
As this post’s title says, when you develop code, you generally want it to be the best code possible. You also want to improve it over time if it’s not yet up to the highest standards. This holds doubly true when you’re doing this for free in an open-source project. First, there’s no time pressure to pound out minimally working code, so you can take the time to make it beautiful. Second, everyone else can look at your work, so you can’t hide ugly code in a dusty corner somewhere as you might be able to in proprietary software.
These same concepts hold true for you, not just your code. When you’re contributing to an open-source project, everyone sees what you do and how you do it. Strive to make yourself beautiful in the context of open-source development. What’s that mean? Always challenge yourself, grow as a person, and learn new skills. Just as beautiful code perfectly suits its purpose, beautiful developers perfectly suit their purpose. Their skills and actions exemplify how open-source developers should act.
If you’re optimizing code, you know that you can’t optimize what you can’t measure. That’s why profilers and other methods of instrumentation exist. This concept has a parallel in your personal development. Your instrumentation is goals, and what you’re measuring is your performance against your own goals. The purpose of this, as with code, is to optimize performance for your relevant metrics. How do you know whether you’ve improved unless you’re profiling yourself? What you’re left with if you don’t set goals and track progress against them is that frustrating comment people always say, “It just feels faster.”
Striving for greatness 
Hey Donnie, I agree with you to an extent in the ‘what’, but not necessarily in the ‘why’.
The ‘what’ – as an organisation, we do need goals and the ability to know how well we’re doing at achieving them, and this is something we are sorely missing.
The ‘why’ – I think what you’re talking about, that is personal excellence, is a goal that each developer needs to set and manage individually. Different people have different idea of what personal excellence in their open source work is, and different ways of measuring them (even if these are not well-defined, they do exist).
Basically, what I’m saying is that I agree that we should have a more goal and result oriented approach to what we’re doing as a distribution, and thus, for each project, and the fact that this will take the distribution forward is good enough reason to do it.
Seriously, Donnie.. what exactly did you want to achieve writing those two posts?
If it was about to increase quality of of the work being done in Gentoo, then you obviously forgot that people used to not do what they are explicitly told to, because … they are people you know?
Especially in purely ‘charitable ‘ environment like Open Source projects with example of Gentoo.
People are complex beings and require complex methods to make them get things done the way you want.
If it was about building the base for PR, then I dare to say you shouldn’t as in my personal opinion – while being perfect “techie”, having already enormous input in Gentoo, being precise and more than qualified in technical aspect of improving distribution – you are not qualified to make self-improvement speeches (as your post looks alike) nor to do PR/motivation job as you already did pretty bad job in motivating people by for example dissing long time Gentoo contributor (WIKI) on gentoo-dev for his concerns about gentoo.org web page ….and now this.
It purely kills the spirit of collaboration. And this “self-improvement”/moralization/ideology talk is just as empty as saying “be good man and respect women”. Not that one telling this first needs to show he follows the idea as well (as you know it already) – it’s just talking about it IS NOT GOING TO CHANGE ANYTHING.
Please forgive me talking about it freely, it’s not my goal to prove myself nor offend anyone. Especially not longtime Gentoo contributor.
There are better ways to increase overall code quality and not kill the spirit in the process. Why alienate Gentoo community creating ‘elite’ feel alike as it automatically makes those “non-elite” unwilling to contribute any longer?
About increasing code quality – there’s fairly cheap and wide known idea – code review.
Let’s just create some procedure of *every* ebuild reviewing (at least by one other developer).
This way – people will be motivated to do better work not because they are told to, but because they want to feel and look professional or just don’t want to be laughed at by their friends.
Of course it’s dangerous in situations when possibly some ‘fresh’ developer looks more qualified to do some job and finds some bugs in ebuilds done by “and old veteran” – but that should create ONLY some spirit of healthy competition – especially between developers with not suboptimal social skills and with some level of self-criticism and between those being able to take proper distance to themselves.
Aren’t those the main factors that are keeping it up alive despite personal and technical differences?
regards
I don’t want to be perfect, I want to be happy. So the stuff I do in my spare time has to be fun (in several layers: I want it to be fun then and there; fun to think of next week; fun to look back upon and say “I built that”). Having to answer for the amount of effort I put into something in my spare time will go a long way in creating (real or perceived) pressure.
Your reasons and motivation may be all great. I don’t challenge them. What I do challenge are the methods. Yes, some of the reactions are knee-jerk: nobody wants to be micromanaged in their spare time. Nobody wants performance review meetings for a thing they started because they loved it. You’ll never get that out of people.
Also, I do all the work I do (as an arch team of one person, mind you) because I like it and I like that I can devote as much effort to it as I want. Yes, there are expectations both from the outside (users want foo stabilized) and from the inside (I want to do this right). That’s enough pressure. Remember: even without reviews and goals and whatnot, this is sufficient pressure that some people burn out.
I’m not one for threaten with “do that and I’m out of here!”, but if I had to make a goal plan which caters to some (to me) artificial structure; with – worse yet – deadlines, I definitely would pack my things and do my work in an overlay outside of this managerial structure.
Note that I agree that there need to be rules and some way to deal with slackers and people who just go AWOL for months. But pressing everyone to report monthly to somebody who deems their work worthy or not (no use in setting goals that never get evaluated) is just going to raise blood.
Hi,
I am no Linux guru, but a happy Gentoo Linux user since 2004. I don’t think that your plan will workout, as with pressure you can’t achieve anything. You can motivate people, but if they don’t work on gentoo linux for fun, you can’t force them to get better, faster etc… And you can’t tell them to be more motivated. The circumstances are what makes a project different. If you don’t enjoy what you do your motivation will decline.
How about lowering the barriers to help adding stuff to the tree or becoming an arch testers?
In KDE they have something called “Junior jobs”. I don’t know if these are a success, but I think that it might help to introduce new developers to the community.
Another idea would to split packages in various categories from A to D, where packages of category A are critical for the system integrity, where others of category D can be overtaken by some freshman.
Also it could help if the herds which are in need of new developers announce, that they need new people.
In case of the kernel team, it seems that Daniel Drake found some motivated and talented helpers.
Perhaps it has something to do with Daniel, as he seems to be a quite nice person, if you read his posts where he encourages people to ask questions again and again to understand the issues around the linux kernel in gentoo tree.
In the hope, that gentoo has some more succesful years,
Richie
you == we?
After reading both posts, my suggestion… If you really want to push your ideas, try it on a small subset of gentoo devs, say, to begin with, the ones who are likely to follow your lead. You will have feedback from a test sample of devs. If its a really great way of doing things, other devs will slowly choose to use the same model. If it proves otherwise, scrap it.
“Your instrumentation is goals, and what you’re measuring is your performance against your own goals.”
True. And it a good thing to keep your goals and progress in mind. However, I guess its totally unrealistic to expect devs to publish their goals: Because for every sane person it would begin with “Here are three top priority goals that are all ranked above my work for gentoo, and if I have those covered I will commit myself to these gentoo specific goals.”
Thats basic time management (see wikipedia Time_management/ABC_analysis): gentoo rarely will be an A priority for an individual. Its different with contracted workers/employees: by entering an contract, the resources are already alotted for a specific set of goals _as_ _long_ _as_ _the_ _contract_ _holds_. An volunteer based project is different: there is no contract and you wont slip one in by setting goals. Anyone dumping gentoo goals because he lost his job or has an emergency in the family is doing the Right Thing(tm). So individual gentoo devs are by definition not a planable resource.
However, most of gentoo work is like having watch on a ship: very much maintainance. I think much would already be won by:
– setting measureable team goals for groups of ~ 10-15 devs
– having a two dev team being responsible for a two-week turn to work towards the goal (exchange one dev per week, make sure that the guys/gals at the helm are volunteers: no dev should be required to be at the helm)
– the devs at the helm are responsible for the _management_ of the goals: they need to keep sure someone is working on the important goals.
– This needs to be done in public and on time (Colorcoded dynamic status website showing goals, resources and progress?)
– The devs at the helm are not required to do the work themselves, if resources are missing (however they are free to choose so).
– However they required to communicate a lack of resources for a specific important goals by all possible means (GMN, forums, irc) – even when they are repeating themselves.
– Goals that are not actively worked on for a period of time depending on priority, on average three month (every dev had a chance to be at the helm by then) need to be escalated: the team and the council need to work out a plan how to attack the goal. Anything but “Just continue another three month” is allowed:
From “Organize face-to-face hackatron to meet the goal at the next open source conference” to “Drop goal”.
Have Fun,
Björn
I do think that Björn Michaelsen provides a more realistic way to implement Donnies ideas.
I also prefer Björn’s version.
Donnie, here are a few “open” points that might explain why you’ve been getting tough feedback.
– You mostly talk about how to kick out “underperforming” devs (or kicking out trolls, which might be a great idea). But aren’t devs entitled to focus on their life and away from Gentoo every now and then? You can’t expect devs to justify their own lives to Gentoo, that would be plain rude. Threatening them to kick them out is even ruder. I sense both communication and attitude problems here.
– Now, apart from kicking out people, how about ideas to get in new recruits? If you tell them “you have to work your ass off for Gentoo or you’re out”, you will scare a lot of people away. What about people who can’t devote more than 2 hours a week to a distro… Are they unwelcome?
– IMO you should explore combining your ideas with distributed approaches advocated by others. Apply you ideas to only a restricted body of “core” people: council, devrel, userrel, 2-3 leads for big teams. Then, for the time-consuming everyday work (ebuild bumps, etc), enable a distributed workflow — look for inspiration at Arch Linux, Exherbo, Funtoo. Seriously. Then you get both easy involvement of extra people (easy opt-in, easy opt-out: very important) and an efficient body of “core” people to take directions for Gentoo.
Anyway, thats’s just my opinion. In any case, thanks for your work in Gentoo and thanks for caring.