On Fri, 2006-08-25 at 19:13 +0200, Wernfried Haas wrote: > On Thu, Aug 24, 2006 at 06:29:03PM -0400, Chris Gianelloni wrote: > > Quite frankly, I think that with a properly run community, there should > > be no need for a "Developer Relations" project, since it should be > > mostly self-policing. > > With 300+ people, i severely doubt self policing would work. I assume > you were mostly thinking about conflict resolution when you wrote > this, but there are other things like
You assumed wrong. While I was mostly thinking about conflict resolution, I still don't think that in a properly run project there is a need for an "HR" project. > - recruitment This goes into the whole thing about bringing people into the project, as well as having a longer probation period. The mentor should really be responsible for the developer. If things were working smoothly, there really shouldn't need to be much work done for recruitment. Remember, we're talking a meritocracy here. We shouldn't just be bringing on some guy because he says he'll do something. We should be bringing on people that have *proven* that they can and will do something. > - retirement of developers that > - quit > - go AWOL See, you missed that we're talking with the idea of people belonging to a project. If you work on my project and quit, I'll know. If you go AWOL, I'll know. I can then simply ask Infra to remove your access. It really should be that simple. If Infra is unable to do so due to being understaffed, then they should get more staff. > etc. > > In an ideal world with a self-policing community this could work out, > however i rather tend to assume one of these things happen in the real > world: > - People get recruited by anyone in whatever way and have no idea about > our policies, breaking the tree in their first commit. Uhh... like this hasn't happened in the past? > - Developers retire and no one removes their access due to lack of > procedure If the developer belongs to a project, the manager knows it and asks for their removal. Is there need for any more procedure than that? > - Devs go AWOL, no one notices. If someone notices, perhaps he starts > volunteering doing this kind of clean-up work, and technically a new > devrel project emerges. See, you seem to be assuming that I haven't thought this through. It would be impossible for a developer to go AWOL without their manager/lead/whatever you want to call them noticing if everyone were a member of a project. This doesn't mean you can only be on one project, it means you must be on *at least* one project. No more projects, no longer a developer. It's simple, yet effective. > > Beyond that, the leadership should have the power > > and the ability to take care of problems in a timely manner without the > > need for droves of bureaucratic process. > > The process (http://dev.gentoo.org/~plasmaroo/policy.xml) is > reorganized and should fulfill both your concern for a timely manner > and is much less bureaucratic. It does not fulfill my concerns in any way. Developer Relations is not Gentoo's leadership. > Also, there's a lot of stuff happening other than the conflict > resolution stuff with regard to ombudsman and often kloeri resolving > things - you don't read that on the news, but i'm not sure if council > members should spend a lot of their time to resolve silly conflicts > between devs, they're elected make decisions, not obsolete devrel. ;-) With a proper structure, the council wouldn't need to be concerned with this sort of thing. Here's an oversimplified example. You are in projects A, B, and C. You haven't done anything for project A in six months, and the manager has noticed, and removed you from his project. He looks to see if you are in other projects, which you are, so he is done. He *could* email the other project leads at this point to see if you're still active, but it wouldn't be required. Each project maintains itself, after all. Project B has done the same since you haven't done anything for them in 3 months. Project C's manager notices that you haven't done anything in 2 months, with no word that you were leaving. He also notices that you aren't in any other projects, so he reopens your dev bug and asks infra to retire you. Process completed and no council involvement, whatsoever. The same sort of process really should be used for conflict resolution. Hell, at least our current policies dictate this, but it never happens, in practice. Instead, everybody goes directly to devrel. If two developers within a single project have a conflict. It goes to that project's manager. If it is between two devs in two projects, it goes to those two managers. The only reason it would need council involvement is if the managers cannot make a decision themselves, or possibly on appeal. There's really no other reason for council involvement. > Btw, the new policy also includes the possibility of refering a > decision to the council in certain cases, see "Resolution and Appeal". I've read the policy. > > I'm sure nearly every member > > of devrel would agree that they would love to see a Gentoo where devrel > > simply wasn't needed. > > I assume you're only refering to conflict resolution again, and i > agree it would be great. I just don't think this is ever going to > happen as long there are more than 50 developers. Quit assuming I mean anything, you're batting zero for two right now. Luckily, I wasn't asking if you thought it was possible. I've merely been stating that it should be possible. There are countless projects out there, many with many more developers than Gentoo, that are capable of maintaining themselves quite well. Why are we so different? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
