Re: NM frustrations...
I swore I was not going to get into this thread, but here I am ;-)
I only have two things to say:
1. James (the current DAM) does not deserve the sludge that has been
shoveled onto his plate. I can personally attest to his integrity
and dedication to the project. Any suggestion that he would act in
other than a completely professional manner is pure FUD.
2. From what I know of the process (being its principle architect) I
would suggest that the cause in the variability of passing the DAM
stage rests completely with the quality of the AM report. A short
look at the archives will indicate the wide variation in the quality
of these reports.
Well, actually three ;-)
3. Applicants to the new maintainer process should never take any
ambiguous behavior in the process to be directed at them personally.
Too many applicants judge their condition to be based on something
that they personally did to piss somebody off. This is almost never
the case in the NM process. The process is objective, but it is made
to work by individual humans who are not always so.
and a short summing up ;-)
I understand that recently James has been "trapped" away from home with
poor connectivity, and like all of us his real life tends to get in the
way of the more important things in life (like Debian). If he does his
work anything like I do, often several weeks can go by without time to
work on my packages, so that when I finally do get a weekend day to work
on them I take the easiest to fix first, doing what I can in the time I
have to work.
If you couple this work practice with the variation in reports, then I
would be forced to do what I could with the time available, and thus take
the easiest applicants first. When I had larger blocks of time to work,
then I would tackle a few of the harder applicants.
The real problem is that a report that simply enumerates the steps and
states that they have been completed is no more information than the
database checklist. Under these circumstances, the DAM must treat this
applicant as though they have just applied and get all of this material
via the contact phone call, which is why the acceptance process stopped in
the first place. Each step must be mirrored in the report with real
content. Logs of e-mail or IRC conversations giving statements by the
applicant that answer the issues. A copy of the key and the signed
document that associates the applicant with his key. (Other documents if
the key is not signed by another member)
With a complete report, it is very much easier for the DAM to decide that
the applicant meets our standards.
Debian is very divided on the membership issues. On the one hand, we want
to accomodate everyone who wants to help produce an exceptional distro,
while on the other hand we want to exclude the dolts and troublemakers
thus improving the climate of the group.
These are mutually contradictory ideas when put in the context of the
"Open Development Model" that Debian has always worked under, yet almost
every member is well aware of the frictions in the group, the disatisfied
applicants, the problems with release management, etc...
And worse yet, almost everyone has their own solution to the problem ;-)
Here is my contribution.
Everyone who has ever looked at the statistics board has noticed the one
field that never has had any applicants. I refer to the "On hold by DAM"
What I propose to do is to work out a procedure with James by which he can
put applicants on hold who need more detail in their application report.
When the missing components have been supplied, the DAM can remove the
hold and finish the processing.
While this may not make any of the stalled applications move any faster,
it will at least give clear indication to the applicant as to the nature
of the stall.
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: firstname.lastname@example.org Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-