[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian account] I request your attention



In-Reply-To: <[🔎] 20010806201243.C459@wiggy.net>

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.

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.

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



Reply to: