I view Gentoo as a bunch of teams. Some of us are on different teams internally (releng, portage, bsd, x86, etc.) and some of these teams may not like each other. However I think as developers there is something to be said for having respect for others.

Respect other developers. Even if you don’t get along with them. Even if you hate them. Even if they are the worst developer you have ever seen. I think that Gentoo should require a minimal level of respect for others. In the end we are all working on the same thing, Gentoo, and that thing should bind us together as a team of developers for Gentoo.

However criticism within a team is important. It is what keeps a team moving forward, it improves the team and it improves the ‘product’, which in this case is typically Gentoo (or it’s related applications).

So a couple of guidelines, for Volunteer Projects, as well as for teams in general.

  • One cannot criticise something without having a better alternative. If thing X sucks, then you better have two things: A reason for why X sucks, and a thing Y that is better than X. Receiving help is a great thing, but just saying something sucks without providing an alternative is pointless, I personally will probably continue to use X. Why? Because I’m doing the work. Unless it’s obvious what Y is and why Y is better, to me there is no reason to switch. The point of constructive criticism is to convince another party that your way ‘is better’ than their way.
  • Criticise an idea, not a person. This is an old adage. Thing X doesn’t suck because person Y wrote it. Thing X may still actually suck, but there need to be concrete reasons why this is the case. So have good reasons to back up your criticism
  • Criticise stuff you know. Commenting on every little encounter or problem in Gentoo makes the conversation hard to follow. Doubly so if you have very little idea regarding the topic at hand. I used to be guilty of this all the time. I like to think I avoid doing it now.
  • Comment on stuff relevant to you. Similarly to the above; you shouldn’t need to comment on things that aren’t relevant to what you are working on. If there is a problem in project A of Gentoo and you aren’t a member of project A, don’t butt in without good reason. That doens’t mean you can’t watch of course, but at the same time you shouldn’t be commenting on stuff unless you are actively contributing.
  • You can’t force people to do work. It’s not possible in a volunteer environment. This leads to…
  • You can’t really complain when people don’t do work. You can however, take their job away in certain circumstances and replace them. This is why the set of roles in Gentoo should be quite fluid. People get bored with stuff, interests change, people move around. If someone isn’t doing the work it should be relatively simple for someone else to pick up the slack. Some projects have a problem with this fluid approach.
  • You won’t get your way all the time. This is a project with well over one hundred members. Most of you are smarter than me, and many of you are smarter than each other. My ideas are not always the best, and neither are yours. Thus as a developer and as a team member you must be prepared to realise when your ideas may not be the best. Accept improvements given by your peers. Accept criticism. Don’t complain when something is decided and your idea isn’t chosen.
  • Remember to have fun working on stuff. In the end that is what this is supposed to be; fun. If you find yourself not having fun, taking a break may be advised. You don’t need to work on this stuff 24/7, you can take a break for a few days and be fine.
  • Don’t own packages. People will sometimes make changes throughout the tree for specific events, upgrades, or to fix a problem. Don’t take it personally if someone touches your package to fix something unless they break it. If they break it, inform them that they did so and what they broke. They may fix it for you (if they know how) or may ask you to fix it. If they break your packages often, talk to them about it, and then their project lead, etc…
  • Miscommunication is the root of all evil. Some developers don’t speak english as a first language. Some developers do speak english as a first language but suck at it. If you don’t get something, assume you’ve misunderstood. If someone makes a remark on an ML that seems inappropriate, assume you’ve misunderstood. Probably the most amusing thing is to see someone make a joke on a mailing list and then seeing someone that didn’t get it reply with a “Wow that was completely inapprorpiate!” response. When arguing, make sure you know that you and the other party are talking about the same thing. Misunderstandings can be based on bad terminology as well as language barriers. Part of determining when a misunderstanding has occured comes with experience (I’ve done tech support for 3+ years, so I assume I’ve misunderstood and attempt to clarify as soon as possible, lest the conversation last 20 minutes with me and the user talking about two different problems.)

I think that about covers it. I’d also like to add; Respect our users. Obviously this doesn’t apply to users who do completely retarded stuff like post ASCII Hitler on bugzilla. However I think many developers assume users are completely retarded and enjoy bashing them. Remember that as a developer you interact with a tiny portion of Gentoo’s userbase. There are good users out there, I’ve met with them, talked to them, and developed with them.

Once again, I’m not saying ‘be a goldenboy’ but we were all n00bs once. If someone comes up to you and asks a stupid question you don’t need to be a smartass about it. If a user is giving you a problem you always have the option of CC’ing userrel or otherwise getting us involved.

Rant over ;)