On Thu, Feb 22, 2001 at 05:03:58PM +0000, Dale Scheetz wrote: > 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. I don't want to come across sounding like I'm bashing him, and I'm sorry if I have. He wouldn't be in such a position if he was not trustworthy and dedicated. I'm more trying to point out the problem with having him as the single point of failure. As you mentioned elsewhere in your mail he had been cut off from decent connectivity for some time. It sucks that that should cause the whole NM process to grind to a screeching halt. > 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. I took a look at my AMs report in the list archive (I don't even remember the name of the list...but there is one!) and compared it to some others (ones that had moved through the DAM queue more quickly). There didn't seem to be much difference. James has not contacted me or my AM to request more info. > 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. I don't take it personally, in that I don't feel offended. I do find it very unfortunate that (maybe because he's overwhelmed by DAM requests?) James has to prioritize things the way he has. He's stated publically that the DAM process is not FIFO, which is fine. But it doesn't seem right that somebody should be elevated to such a priority that the only have to wait in the queue for 2 days when another person has been in it for over 200 days. <snip> > 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... I actually support a slightly more exclusive development. I just want to be able to upload my packages to the FTP server. I support the idea of having some kind of a "core" team that is somehow "more" of a Debian developer than somebody who just completed the NM queue. I don't want to really get in to that now. I just want to be able upload my packages. 8^) > 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. That's assuming that there is some missing info or that something is needed of the applicant or the AM. In my case, I suspect that's not the case. Being put on hold would probably frustrate me even more, as I'd end up worrying that I've been forgotten and that I'll never be taken off hold. But, if the hold status is used properly (i.e. James notifies the applicant promptly of the missing info) then it could help. noah -- _______________________________________________________ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html
Attachment:
pgpxnBtpX_Dya.pgp
Description: PGP signature