A patch to Step 5: Evaluation and Check-in
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[Hmm. KMail allows me to use my mouse to paste things in the middle of a
message just before sending it :) This is the correct version. Please
disregard the previous mail.]
Wichert Akkerman <wichert@wiggy.net> writes:
> I am much more in favour of the other two options:
> * do the reverse and reject if not approved in a certain timeframe
This would give the DAM or DAMs the power to reject someone simply by not
approving him. He[+] would not even have to make an explanation.
As a matter of fact, the Check-in step is not supposed to be the step where
the decision is really given. It is the previous steps in which the decision
of whether an applicant is eligible for acceptance is given.
I'm summarizing from Step 5: Evaluation and Check-in:
- ---------------------------------------------------------------------------------------------------
Step 5: Evaluation and Check-in
After applicant complets all "tasks and skill tests", the AM submits a
report to the NM-Comittee which is a detailed report including a
recommendation for acceptance or rejection, with specific reasons for the
decision. Same report is then sent to FrontDesk and DAM with additional docs.
A. Evaluation
The NM committee reviews the AM report which is simply a check to verify the
steps involved. NM comittee may accept, reject or request additional
information. (The conditions are given in the original text)
B. Check-in
DAM may request more information. When DAMs are "satisfied", they will create
the account.
- -----------------------------------------------------------------------------------------------------
That is, currently DAM needs to be "satisfied", which is not a clear
condition. Check-in step is definitely ambiguous. On the other hand, the real
evaluation is not made by DAM but by the NM comittee in "A. Evaluation".
Your proposal to reject the application if it does not pass "B. Check-in" can
only make the situation even worse, as it essentially gives DAM absolute
power to reject an application even though the application may be perfect.
Right now, DAM simply does not create accounts for people he does not like[*]
and expects them to give up on their applications. Here is my suggestion:
I think that the "sub" steps A. and B. have too much overlap. If additional
information is required, it is the NM committee that can make the most
informed decision. Likewise in the final decision to approve or reject an
application. This final decision is reported publicly. The DAM promptly
creates an account and manages the technical aspects of account creation as
soon as NM committee accepts application.
This is my fix to Step 5.
Such a change ensures much better treatment of applications; it is open and
unambiguous.
To provide fair processing of applications, the NM committee has to give the
final decision or request for information exactly in the order of the date AM
report was given.
There is no need for additional concern about "B. Check-in" which is trivial
in this scheme. DAM has to create the account once application is accepted.
Rationale: Power is shifted from the single person who is called DAM to NM
committee in accordance with Debian Constitution. Fair, open and precise
evaluation of applications is facilitated.
It would not be fair to either accept or reject an application simply because
DAM did not approve it within a certain time frame.
Regards,
[+] That happens to be a single person: the supreme operator James Troup
[*] Which I really assume to be the case right now since he has not even
bothered to say a single word on the situation, ultimately showing his degree
of respect for the concerns of developers and applicants.
- --
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7cB/gfAeuFodNU5wRAlGRAJ9jE1Z3K2EKLhisBC3GO1AWto38vQCeNQ9L
Wcv9rA7puFK07FUGV4/KHbA=
=tl9J
-----END PGP SIGNATURE-----
Reply to: