AM report contents, was: Re: task & skills
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: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Reply to: