[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Fwd: [RFC] Making NM 'by recommendation']



>>"Jon" == Jon Eisenstein <jeisen@mindspring.com> writes:


 Jon> Another possibility that I imagine has been suggested before is
 Jon> that of a tiered developer system. We already have an unoffical
 Jon> 3-tiered system, maybe with more levels: Senior Developer,
 Jon> Developer, Non-Developer. I

	We do? And who are the senior developers, then? In some
 respects, all developers are equal -- they ahve the same rights to
 vote, the same rights to their package as anyone else. 

	The only difference there is comes is in the opinion of the
 fellow developers -- when it comes to an issue (like this one) where
 people have not made up their minds, then the perception of
 competence of a developer counts -- whether it is handling a large
 and complex package well, or making rational posts that people agree
 with.

	It has little to do with seniority. Perception of competence,
 reasonableness, ability t o work as a team member, ability to
 convince one's peers -- that is the major difference, as far as
 differences go, between developers (except, of course the DPL -- and
 again, the DPL is selected partially based on the perception as a
 developer, so we come full circle). 

 Jon> worked for a long time on a MUX that, though it had
 Jon> significantly fewer staff, did work well with such a system
 Jon> (Senior Developer, Full Developer, Junior Developer,
 Jon> Trainee). All members of these groups had full privileges (and
 Jon> I'm not suggesting that this part be copied fully), but had to
 Jon> report to a higher level regularly. After proving that they had
 Jon> certain skills, the person could be promoted by suggestion of
 Jon> their superior (of one level above).

	I am not so sure I want this tiered developer hierarchy. We do
 not ahve core developers. we don't have developers who are more equal
 than others. And, for that reason, I think that the NM process needs
 to be discerning -- since any such inequality, I think, would be more
 deleterious to Debian's health than a scarcity of developers. 

 Jon> Now, who would want to have to check up on these people
 Jon> regularly and put in all this extra work, you may
 Jon> ask. Personally, I wouldn't mind doing this. It's the person
 Jon> who's trying to become a higher status that has the
 Jon> responsibility of showing what they've done for Debian. If they
 Jon> haven't reported in a long time, they shouldn't be checked up on
 Jon> with more than a "I haven't heard from you in a while; you still
 Jon> working on things for Debian?" And the reports that are sent
 Jon> wouldn't even be that long. Just a quick note to review (shorter
 Jon> than most messages on this list) showing what they've been up
 Jon> to.


	The bureaucratic and boring work of a supervisor is not the
 only drawback of this scheme. You are ignoring the psychological
 aspects.Having a hierarchy  fosters political maneuvering, jostling
 for post ion to be alpha developer. Though this works in a corporate
 setting, I doubt this shall work in a volunteer organization. The
 motivation for developers, different though they are, generally
 contain the requirement that working for Debian, at some level, be
 fun. You bring in the core developers, and the novices, the
 aristocracy, and the hoi polloi, it is going to be less fun for the
 serfs. (This was a factor in me joining Debian as a volunteer rather
 than going to the more mature *BSD's). 

	Apart from being a Linux distribution, Debian is also a
 delicate balanced social organism. Such tinkering at the levels you
 advice are likely to destroy what we have. 

	manoj
-- 
 "What I've done, of course, is total garbage." Willard, Pure Math
 430a
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: