OK, I've read all the postings on this thread, and I must first correct some incorrect information presented there.
1. The DAM (currently James) IS the final authority on acceptance of new maintainers. It is the DAM that must be satisfied with the qualifications of the applicant. In past discussions of this subject, the response to this statement has been: "So what are we here for if we have no authority?" I'll try to answer this question once more, with close attention to the issues that have been raised in this thread. Our primary job is the collection and recording of the critical information needed to make an adequate assessment of the applicant. We do that by executing each step of the AM process. The most critical step in the AM process is the production of the final report. We have a wide variety of information content across the reports received to date. This wide variability is a problem that may be addressed by the following. Quality vs Speed The biggest question in this thread seems to be: "Why should I work hard collecting detailed information on my applicant, requiring clean packages, and otherwise being diligent in my duties when other AMs slap together a report as quickly as they can, paying no real attention to their individual applicants?" Assuming that the final report contains all the details of the application process and communicates the critical information to the DAM, then the advantage of your work is clear. You provide all the information needed for the DAM to decide on acceptance, making it possible for him to move forward with the assignment of accounts. Whether you do the work or not, if your final report only gives your option that the applicant is suitable for membership, the DAM is left a substantial bit of work, including some kind of phone conversation, before that applicant can be processed. Personal Contact Several AMs have made specific requests for applicants who are already known to them, from work or school interactions, suggesting that they can process these applicants more quickly than others. In one case, now several months old, I am still waiting for the AM to accept the assignment. In another case the applicant was processes in 1 day. In the fast case, the AM asked about a month in advance, and clearly did the work while waiting for the assignment. I have no problem with this, however, in this case the report was almost completely devoid of content beyond the AMs opinions of each stage of the process. When you have personal contact with your applicant, it is still important to have e-mail records of the applicants opinions intentions and previous work, signed by them, to be included in the final report to the DAM. It is presentations of this type that are most useful to the DAM. Buggy Packages Obviously we want maintainers who can build correct packages. The question the arises: What constitutes unacceptable packaging? 1. We all can make mistakes, more often when we are working in new and unfamiliar territory. 2. Demonstrations of skills can not be considered failures merely because the particular test project was less than perfect. 3. Reactions to mistakes are far more informative than the mistakes themselves. In general, receiving a buggy package from a prospective applicant should be seen as an opportunity to point out tools that make it possible to do the job right. While missing copyright clearly makes the package a problem, this really doesn't say much one way or the other about the applicant's technical skills. This is another opportunity to point out the importance of obtaining a free license as well as a valid copyright, on any package being built for Debian. Finally, remember if we expected bug free packages, we could shut down the BTS ;-) Seriously, if buggy packages are any kind of acceptance criterion, then many of our best developers would be kicked out of the project, along with many of those less skilled, like myself. The critical question is how the applicant responds when these items are pointed out. If we insist on only accepting those who make no mistakes, we are only going to have folks who don't do anything. Conclusion I have tried to remain neutral about internal AM processes. Many of you use IRC almost exclusively to contact your applicants, and complain when time zones interfere with this process. Sorry, but we are an international organization, and if you can't communicate with folks in "inconvenient" time zones then Debian probably isn't for you. Others see an advantage to dealing with someone from their "parent" country. This is fine as long as the final report can be generated in clear understandable English. My hope was that the "mind share" among the various AMs would provide useful answers to all AMs. One of our most recent AMs is working on a package of scripts and procedures to help AMs manage information collection from a large number of applicants. I hope that discussions can center around this package as a means for discussing internal AM processes. I'm very unwilling to discourage rapid processing for its own sake. I strongly encourage the creation of complete and accurate final reports from every AM. Just because we have a wide range of skills and available time doesn't mean that we all can't focus on the same set of important details and generate quality reports as a result. Producing many rapid reports with no content does no one any good and surely wastes the time of the AM providing those empty reports. Taking the time to produce a complete and accurate report is always a valuable contribution. One final note: I do the best job I know how, not to satisfy others, but to maintain my own self image for my own satisfaction. If you can't convince yourself you are doing the right things, how can you expect to convince others? Our lives and actions are a direct expression of our self image and act as examples for others of "correct" behavior. As long as you are producing the best product you know how, almost everything else is secondary. Don't stop just because someone else is doing it different. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-