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

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



Manoj, interesting discussion but...

Having different level of maintainer may not be all that bad idea.
Please consider.

Of course technical competence must be there.  Consider following 
argument of me who thought about becoming maintainer but wishes 
to be a less privileged (junior) maintainer.

---
Does debian have enough people to maintain bug free distribution as
you wish to be?  Does people have enough time and resources to be
full time maintainer?  Give busy people some chance!

My previous bug report experience tells me that people who maintain 
required or important packages are quite responsive if bug reports 
are reasonable.  (I consider you are one of this kind.)

I also think all functional bugs needs to be fixed within 30 days 
if someone file a working patch.  Or at least some action needs to
be taken, like reply by mail.  Don't you agree?

But even with a clear patch given, I got no response for a package
over a month.  It gets especially irritating since that was a bug 
introduced by the maintainer on the code portion which _I_ _WROTE_.  
I felt like I want to become the MAINTAINER for that optional package!

Current maintainer gave me a letter telling me "(he is) busy and 
may orphan package soon" after long silence...

But after reading this thread, I realize that becoming maintainer 
means gaining the same privilege as you.  I do not need that much 
privilege.

All I want is an access to the particular optional package.  Debian 
can assign multiple people (like 3-4) of these junior maintainers 
to non critical packages.  Give these people a limited write access 
(require 2 signatures for upload) and no right for the non-maintainer 
upload.  This kind of arrangement shall make maintenance of less 
interesting packages (Optional and Extra) more responsive.  

Give these junior maintainer a less voting power (like 1/4 or 1/8) 
but this ensures busy people can help debian too (redundancy).

ALSO THIS SCHEME IS LESS STRESSFUL TO THE SENIOR PEOPLE LIKE YOU.  
No more lecuring but mutual check.

Give people a chance to move up the previlege every 3 month or so 
with growing with responsibility after proving they can do the job.
Doing something is better than waiting for a year too.

Oh by the way, current application system is so prone for abuse.
Please at least require applicant to file his application through 
GPG-signed e-mail using Debian system (No Outlook nor unfolded 
message).  Since debian is GNU, requiring Mutt or GNUS/EMACS
may not be a bad idea at all.

Just a thought,

Regards,

Osamu  (Not even applied for the developer...)

PS; I used junior/senior to refer technical and organization position.

On Sun, Jan 28, 2001 at 01:25:35AM -0600, Manoj Srivastava wrote:
> >>"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 unofficial
>  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 have 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). 
......

-- 
+  Osamu Aoki <debian@aokiconsulting.com>, GnuPG-key: 1024D/D5DE453D  +
+   Fingerprint: 814E BD64 3288 40E7 E88E  3D92 C3F8 EA94 D5DE 453D   +
+   === http://www.aokiconsulting.com ======= Cupertino, CA USA ===   +



Reply to: