Re: DAM queues processing
On Thu, Jun 25, 2009 at 10:37:30PM +0200, Emilio Pozuelo Monfort wrote: > This is how I see the process right now, from the applicant's POV: > Actually it is: > - Applicant applies > - DD advocates > (wait1) - FD ask NM what they do in Debian? [1] Currently, this is a email sent manually. - NM answers FD. If applicant is active, it can take some time :) - FD evualuates and in some cases put the applicant in hold. (wait 1.5 -> you are ok, wait for AM) (wait 1 extended -> wait until you have contributed enought to get AM) > - AM assigned > - Work with the AM (P&P, T&S and whatever is needed) > - AM sends report > (wait2) > - FD checks the application > (wait3) > - DAM reviews the application > (wait4) > - DAM creates the account > - Key added to the keyring > - Shell access to developer machines > This "sending a email" step is no documented in the webssite and I do not see it a as a oficial step. But it could be included in the "FD evualuates NM to assign AM" part. [1] http://svn.debian.org/wsvn/nm/trunk/doc/front-desk/templates/activity-poll?rev=994&sc=1 > > - Reducing wait1 is complicated. Some possibilities for accelerating this are: > + Recruiting more AMs This is not easy. AM is not a "fun job" and recruiting DDs who are not really interested in AMing (mentoring and teching in some level) is not a good idea. If you do not like doing this too much and you do it because you kind of feel forced, you will tend to procrastinate to answer your NM :) I have not lived this, but I have seen this in others DDs who kind of feel forced to help with NM. Also, you have the DDs who would work as AM but do not fully like the current process for many different reasons. For example, dislike the templates. > + Reducing the time an AM spends with the applicant. Many people dislike > this if it means less questions, so probably not a good idea. > + Requiring applicants to apply late rather than soon... As I pointed earlier in this thread, this is mostly responsability of the advocate. DDs should not advocate people until they have shown some dedication, good skills, motivation, etc. > - wait2/3 could be merged by removing the duplicate work of both FD and DAM > reviewing applications. Only one body should do it (e.g. DAM, and if wanted > FD members joining it). That will remove wait2, and if more people joins > DAM, reduce wait3. > Better guidelines to AM on how to do the AM report and send this direclty to DAM, so we do not need the "check for completeness" step. Some guidelines in what am should check together with some freedom for the AM in how to check this would be interesting. Ana -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
On Thu, 25 Jun 2009, Lucas Nussbaum wrote: > On 25/06/09 at 22:37 +0200, Emilio Pozuelo Monfort wrote: > > [...] > > - DAM reviews the application > > (wait4) > > - DAM creates the account > > - Key added to the keyring > > - Shell access to developer machines > > > > [...] > > > > - I don't know why there is wait4. I guess it's because DAM members process > > people in batches, but IMHO if you have already reviewed an application > > and > > accepted it, the account should be immediately created? Is there a (good) > > reason for this delay? > > > > - I have no idea whether the keyring and machine access stuff take another > > big > > delay. > > wait4 used to be a big problem in the past, because the person managing > the keyring and creating the accounts was not responsive enough. > > It was solved a year or so ago by splitting the tasks differently. DAM > now reviews the application, and submits RT tickets for the keyring > addition and the account creation. Those tickets are processed by DSA > (for the account) and keyring-maint (for the keyring), and both of those > teams are responsive currently. > > (the above is my perception of how things work, so I might be wrong, but > it's not properly documented anywhere anyway.) Correct. There is no 'DAM creates the account' step. If you want to have a step there it's 'DAM sends request to keyring-maint/DSA', but I suppose that's identical to "finishes review with a positive result". -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
On 25/06/09 at 22:37 +0200, Emilio Pozuelo Monfort wrote: > [...] > - DAM reviews the application > (wait4) > - DAM creates the account > - Key added to the keyring > - Shell access to developer machines > > [...] > > - I don't know why there is wait4. I guess it's because DAM members process > people in batches, but IMHO if you have already reviewed an application and > accepted it, the account should be immediately created? Is there a (good) > reason for this delay? > > - I have no idea whether the keyring and machine access stuff take another big > delay. wait4 used to be a big problem in the past, because the person managing the keyring and creating the accounts was not responsive enough. It was solved a year or so ago by splitting the tasks differently. DAM now reviews the application, and submits RT tickets for the keyring addition and the account creation. Those tickets are processed by DSA (for the account) and keyring-maint (for the keyring), and both of those teams are responsive currently. (the above is my perception of how things work, so I might be wrong, but it's not properly documented anywhere anyway.) -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: DAM queues processing
Hi all, This is how I see the process right now, from the applicant's POV: - Applicant applies - DD advocates (wait1) - AM assigned - Work with the AM (P&P, T&S and whatever is needed) - AM sends report (wait2) - FD checks the application (wait3) - DAM reviews the application (wait4) - DAM creates the account - Key added to the keyring - Shell access to developer machines This is in the case the applicant is accepted everywhere and becomes a DD, of course. So as I see it, wait[1234] are the bigger waiting periods, and reducing them won't decrease the NM process quality (as some people complained if the number of questions was reduced). - Reducing wait1 is complicated. Some possibilities for accelerating this are: + Recruiting more AMs + Reducing the time an AM spends with the applicant. Many people dislike this if it means less questions, so probably not a good idea. + Requiring applicants to apply late rather than soon... - wait2/3 could be merged by removing the duplicate work of both FD and DAM reviewing applications. Only one body should do it (e.g. DAM, and if wanted FD members joining it). That will remove wait2, and if more people joins DAM, reduce wait3. - I don't know why there is wait4. I guess it's because DAM members process people in batches, but IMHO if you have already reviewed an application and accepted it, the account should be immediately created? Is there a (good) reason for this delay? - I have no idea whether the keyring and machine access stuff take another big delay. What do people think? Best regards, Emilio signature.asc Description: OpenPGP digital signature
Re: DAM queues processing
On Wed, Jun 24, 2009 at 02:37:42PM +0200, Wouter Verhelst wrote:
> The FD's responsibility, as a 'New Maintainer Front Desk', is to
> ensure that the new maintainer process runs smoothly, and to take a
> bit of the grunt work off of the DAM. If stuff passes front desk,
> it's assumed that it'll pass DAM too, unless FD fucked up.
>
> However, the final decision of who gets to be a DD and who doesn't
> is not with FD; instead, that decision lies with the DAM. They have
> to make up their own mind.
I understand very well both this statements. My problem with the
situation they induces is that there seems to be some useless
bureaucracy in that, which I proposed to fix merging somehow the FD &
DAM roles [1].
Let me explain where I see too much bureaucracy. If, as you said,
"passing FD means passing DAM", can't we just skip DAM review if FD
say "OK"? Similarly, if FD says "no, there are still issues", can't we
just avoid passing the file to DAM whose time is precious?
De facto, that would mean delegating the acceptance role to FD; if
people are unease with that, just merge FD into DAM, have a larger DAM
team, with internal role distinctions about who is working on
acceptance new members.
A few concluding notes:
- I know that on paper FD is only in charge to check for the
"completeness" of a report and not doing a review, but from what
emerged in this thread by FD members, they de facto do reviews
- given that FD follow more closely applicants than DAM (which only
notices them at the end of the process), they know better applicants
and it is easier for them to do also the final review; (current) DAM
should start from scratch when it receives the applicant file. It
just sounds as dumb to me
Cheers.
[1] again: I'm not claiming that this will solve _all_ NM problems,
far from that, but I think it is pretty easy and will get rid of
some time wastes.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: DAM queues processing
On Wednesday 24 June 2009, Bernd Zeimetz wrote: > FD has mainly two people: Wouter and me. Christoph Berg helps out > sometimes, but has more than enough to do with DAM work. There is no > other FD - they either stepped down or disappeared completely from > Debian. > Would be great to know where FD members are listed so we can get this > fixed... http://www.debian.org/intro/organization: * New Maintainers Front Desk -- member Bernd Zeimetz member Christoph Berg member Michael Koch member Wouter Verhelst Source is in the website CVS, FD is about 2/3 down: http://cvs.debian.org/webwml/english/intro/organization.data?root=webwml&view=markup Just mail debian-www with any changes you'd like made. Cheers, FJP -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
Wouter Verhelst wrote: > On Tue, Jun 23, 2009 at 03:30:13PM +0200, Stefano Zacchiroli wrote: >> But as things stand nowadays, I wouldn't be happy with that outcome, >> given that DAM is more understaffed than FD (2 people vs 4), with >> Joerg also involved in another time-consuming role (ftpmaster). > > Actually, that's not entirely true. Most FD members are inactive > currently; Bernd is by far the most active FD member. I keep intending > to do more work in this area, and manage to stay on top of things for > the most part, but inevitably end up not finding the time to actually do > anything useful. > FD has mainly two people: Wouter and me. Christoph Berg helps out sometimes, but has more than enough to do with DAM work. There is no other FD - they either stepped down or disappeared completely from Debian. Would be great to know where FD members are listed so we can get this fixed... -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
On 24/06/09 at 14:41 +0200, Ana Guerrero wrote: > Lucas, for what I understand, you have been reading (or at least receiving) > the FD email for some months now [1], from even before Bern were promoted > to FD. The goal was helping with some FD tasks without being FD. What > were those tasks? Something we could do better? At the time, there was a need for triaging applicants, both before they get an AM assigned (to detect applicants that were advocated but do not have enough prior contributions to Debian), and during the process. I went through AMs that had been on hold for a long time, and assigned for a long time, to try to detect: - who should be dropped out (people no longer interested in becoming a DD) - who should be reassigned to another AM I did some work on that (only making recommandations, not taking the actual decisions, since I was not officially an FD member), but after bzed became an official FD member, he became super-active and did a lot of great work, and at the same time I became more busy with other stuff, so I did not continue that work. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
On Tue, Jun 23, 2009 at 03:39:10PM +0200, Lucas Nussbaum wrote: > On 23/06/09 at 15:30 +0200, Stefano Zacchiroli wrote: > > On Tue, Jun 23, 2009 at 02:55:42PM +0200, Peter Palfrader wrote: > > Hence I would more welcome one of the following alternative outcomes: > > > > 1) drop FD *and* integrate the current FD people into DAM; it looks > >like accepting new members is the main part of DAM activities > >anyhow, so why bother with an extra advisory board? > > > > 2) change the "It's DAM" fact above, from now on "it will be FD" > > > > How do people feel about that? > > I like the idea a lot. > The idea sounds good, but I think FD does more than "checking for completeness". Lucas, for what I understand, you have been reading (or at least receiving) the FD email for some months now [1], from even before Bern were promoted to FD. The goal was helping with some FD tasks without being FD. What were those tasks? Something we could do better? I see FD does the following: - Checking advocate's email - Asking applicant what does in Debian (via mail) - Evualuating applicant activity and available AMs, in some moment assign AM to NM. - Checking all the report is complete. But not decide. This is the FD approval step we want to remove. FD never rejects, just send the applicant back if something is missing. (*) - Hunting for AMs. - Pinging periodically to AM-NM pairs that seem to be inactive. - ? So, from what I see here, it is not about removing FD but about removing one of the FD tasks. Could we trust AM to write proper NM reports? Maybe improving the documentation of what must be in the AM report would be the thing to do. (*) However, from time to time, I have seen people with incomplete stuff in the DAM stage. [1] http://svn.debian.org/viewsvn/nm/trunk/bin/fd_mailbox?view=log Ana -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
On Tue, Jun 23, 2009 at 03:30:13PM +0200, Stefano Zacchiroli wrote: > But as things stand nowadays, I wouldn't be happy with that outcome, > given that DAM is more understaffed than FD (2 people vs 4), with > Joerg also involved in another time-consuming role (ftpmaster). Actually, that's not entirely true. Most FD members are inactive currently; Bernd is by far the most active FD member. I keep intending to do more work in this area, and manage to stay on top of things for the most part, but inevitably end up not finding the time to actually do anything useful. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
On Tue, Jun 23, 2009 at 02:43:55PM +0200, Emilio Pozuelo Monfort wrote: > If the FD doesn't have the power to decide whether to accept somebody or not, > what is the point of it reviewing candidacies, specially if later the DAM > will review it anyway? The FD's responsibility, as a 'New Maintainer Front Desk', is to ensure that the new maintainer process runs smoothly, and to take a bit of the grunt work off of the DAM. If stuff passes front desk, it's assumed that it'll pass DAM too, unless FD fucked up. However, the final decision of who gets to be a DD and who doesn't is not with FD; instead, that decision lies with the DAM. They have to make up their own mind. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
On Tue, Jun 23, 2009 at 03:30:13PM +0200, Stefano Zacchiroli wrote: > Hence I would more welcome one of the following alternative outcomes: > > 1) drop FD *and* integrate the current FD people into DAM; it looks >like accepting new members is the main part of DAM activities >anyhow, so why bother with an extra advisory board? > > 2) change the "It's DAM" fact above, from now on "it will be FD" > > How do people feel about that? I feel very good about that Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
Emilio Pozuelo Monfort dijo [Tue, Jun 23, 2009 at 02:43:55PM +0200]: > >> I'd be perfectly fine with FD being the last review step, and DAM > >> "just" in charge of creating the account, trusting FD judgement. > >> > >> What would we be missing that way? > > > > What you miss is that I move all problematic candidates to DAM with the > > comment > > "I'm not entirely happy, but its your job to decide..." > > Also it is good to have more than one person read the mboxes, sometimes you > > just > > miss important points/words because you're braindead after reading too many > > mails. > > If the FD doesn't have the power to decide whether to accept somebody or not, > what is the point of it reviewing candidacies, specially if later the DAM will > review it anyway? Or rather, I'd rephrase this as a question: How often does FD reject somebody that was approved by AM? How often does DAM reject somebody that was approved by FD? That might indicate whether any of those processes is redundant. -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
Bernd Zeimetz dijo [Tue, Jun 23, 2009 at 02:54:17PM +0200]: > > If there are too many emails, maybe you should reduce the number of > > emails by reducing the number of questions asked? > > No. > The number of emails rises only if candidates don't answer in a useful way and > the AM needs to ask back. Otherwise the number of emails is more than low > enough. Looking at the last good mbox there're 7 mails to read as all the > questions were answered perfectly. And this is what one should expect as the > questions are definitely not hard. As an AM, I actually prefer it the other way around - Of course, I do not have a FD or DAM hat to wear. But if my applicant's answers are not _completely_ satisfactory, I first ask him to elaborate further. And after a round or two, I end up explaining what I know about the fact. And he usually mails back with some comments regarding my explanation. Yes, I have only processed a single applicant so far, and with ~80 mails, I think some people might hate me - but I prefer to be that verbose on my AM communications. -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
Lucas Nussbaum wrote: > On 23/06/09 at 15:30 +0200, Stefano Zacchiroli wrote: >> On Tue, Jun 23, 2009 at 02:55:42PM +0200, Peter Palfrader wrote: OK, then what I'm proposing is to identify one single entity where the decision is taken. Either is FD or is DAM. >>> It's DAM. DAM has always been the position that decides who is a DD and >>> who isn't. The whole FD/NM thing is just an advisory board to the DAM >>> if you want to call it that. >> Then drop FD, it looks like it is just a waste of time, given that in >> the "problematic" cases the dossier is just handed over to DAM for a >> new full review. >> >> But as things stand nowadays, I wouldn't be happy with that outcome, >> given that DAM is more understaffed than FD (2 people vs 4), with >> Joerg also involved in another time-consuming role (ftpmaster). >> >> Hence I would more welcome one of the following alternative outcomes: >> >> 1) drop FD *and* integrate the current FD people into DAM; it looks >>like accepting new members is the main part of DAM activities >>anyhow, so why bother with an extra advisory board? >> >> 2) change the "It's DAM" fact above, from now on "it will be FD" >> >> How do people feel about that? > > I like the idea a lot. /me too, either of them. Hopefully that would solve the current bottleneck. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: DAM queues processing
On 23/06/09 at 15:30 +0200, Stefano Zacchiroli wrote: > On Tue, Jun 23, 2009 at 02:55:42PM +0200, Peter Palfrader wrote: > > > OK, then what I'm proposing is to identify one single entity where the > > > decision is taken. Either is FD or is DAM. > > It's DAM. DAM has always been the position that decides who is a DD and > > who isn't. The whole FD/NM thing is just an advisory board to the DAM > > if you want to call it that. > > Then drop FD, it looks like it is just a waste of time, given that in > the "problematic" cases the dossier is just handed over to DAM for a > new full review. > > But as things stand nowadays, I wouldn't be happy with that outcome, > given that DAM is more understaffed than FD (2 people vs 4), with > Joerg also involved in another time-consuming role (ftpmaster). > > Hence I would more welcome one of the following alternative outcomes: > > 1) drop FD *and* integrate the current FD people into DAM; it looks >like accepting new members is the main part of DAM activities >anyhow, so why bother with an extra advisory board? > > 2) change the "It's DAM" fact above, from now on "it will be FD" > > How do people feel about that? I like the idea a lot. FD doesn't need to be removed completely. It could stay as a small group (including all DAM members, maybe) in charge of coordinating the assignement of applicants to AMs, but not doing any review of applications. Also, if our DPL is uncomfortable with the idea of adding 3 new members to DAM, he could add them as assistants first. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: DAM queues processing
On Tue, Jun 23, 2009 at 02:55:42PM +0200, Peter Palfrader wrote:
> > OK, then what I'm proposing is to identify one single entity where the
> > decision is taken. Either is FD or is DAM.
> It's DAM. DAM has always been the position that decides who is a DD and
> who isn't. The whole FD/NM thing is just an advisory board to the DAM
> if you want to call it that.
Then drop FD, it looks like it is just a waste of time, given that in
the "problematic" cases the dossier is just handed over to DAM for a
new full review.
But as things stand nowadays, I wouldn't be happy with that outcome,
given that DAM is more understaffed than FD (2 people vs 4), with
Joerg also involved in another time-consuming role (ftpmaster).
Hence I would more welcome one of the following alternative outcomes:
1) drop FD *and* integrate the current FD people into DAM; it looks
like accepting new members is the main part of DAM activities
anyhow, so why bother with an extra advisory board?
2) change the "It's DAM" fact above, from now on "it will be FD"
How do people feel about that?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: DAM queues processing
Peter Palfrader wrote: > On Tue, 23 Jun 2009, Stefano Zacchiroli wrote: > >> On Tue, Jun 23, 2009 at 02:29:20PM +0200, Bernd Zeimetz wrote: >>> What you miss is that I move all problematic candidates to DAM with >>> the comment "I'm not entirely happy, but its your job to decide..." >> OK, then what I'm proposing is to identify one single entity where the >> decision is taken. Either is FD or is DAM. > > It's DAM. DAM has always been the position that decides who is a DD and > who isn't. The whole FD/NM thing is just an advisory board to the DAM > if you want to call it that. Exactly.FD checks for completeness officially. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
On Tue, 23 Jun 2009, Emilio Pozuelo Monfort wrote: > From an NM point of view, my feeling is: > > "I hope the Keyring Maintainers and the DSA don't feel like reviewing > everything > *again* to add my key to the keyring and to give me access to the developer > machines" Speaking with my DSA hat on, the DAM informs us (keyring and DSA team) that there is a new developer. Once the new person's key is in the keyring we then simply create the account. There's nothing to *review* per se since the DAM has already decided that said new user is a DD and our policy is to give every DD access to project machines*. Cheers, weasel *) So, while who or who is not a DD is DAM's authority, deciding who or who will not have shells on d.o machines is DSA's. So in theory DSA could of course decide that we mistrust a given person to such an extend that we will not grant him shell access to project machines. That person would still be a DD by the DAM's fiat, they just wouldn't have a shell on d.o machines. But then things must be really really wrong to have gotten that far. Hopefully not very likely. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
On Tue, 23 Jun 2009, Stefano Zacchiroli wrote: > On Tue, Jun 23, 2009 at 02:29:20PM +0200, Bernd Zeimetz wrote: > > What you miss is that I move all problematic candidates to DAM with > > the comment "I'm not entirely happy, but its your job to decide..." > > OK, then what I'm proposing is to identify one single entity where the > decision is taken. Either is FD or is DAM. It's DAM. DAM has always been the position that decides who is a DD and who isn't. The whole FD/NM thing is just an advisory board to the DAM if you want to call it that. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
Lucas Nussbaum wrote: > On 23/06/09 at 14:29 +0200, Bernd Zeimetz wrote: >> Stefano Zacchiroli wrote: >>> I'd be perfectly fine with FD being the last review step, and DAM >>> "just" in charge of creating the account, trusting FD judgement. >>> >>> What would we be missing that way? >> What you miss is that I move all problematic candidates to DAM with the >> comment >> "I'm not entirely happy, but its your job to decide..." >> Also it is good to have more than one person read the mboxes, sometimes you >> just >> miss important points/words because you're braindead after reading too many >> mails. > > If there are too many emails, maybe you should reduce the number of > emails by reducing the number of questions asked? No. The number of emails rises only if candidates don't answer in a useful way and the AM needs to ask back. Otherwise the number of emails is more than low enough. Looking at the last good mbox there're 7 mails to read as all the questions were answered perfectly. And this is what one should expect as the questions are definitely not hard. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
On Tue, Jun 23, 2009 at 02:29:20PM +0200, Bernd Zeimetz wrote:
> What you miss is that I move all problematic candidates to DAM with
> the comment "I'm not entirely happy, but its your job to decide..."
OK, then what I'm proposing is to identify one single entity where the
decision is taken. Either is FD or is DAM.
You are rightful in asking redundancy, but you can have it within
_the_ entity (e.g., two FD members to independently review the
mailboxes, if you feel its needed).
The current work-flow (as I understand it, I might be wrong in that of
course) looks like very sub-optimal: you have sometimes redundancy
(for the "problematic" cases) and other times you have it not; also
the decision is split among two entities, with no clear responsibles.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: DAM queues processing
Bernd Zeimetz wrote: > Stefano Zacchiroli wrote: >> I'd be perfectly fine with FD being the last review step, and DAM >> "just" in charge of creating the account, trusting FD judgement. >> >> What would we be missing that way? > > What you miss is that I move all problematic candidates to DAM with the > comment > "I'm not entirely happy, but its your job to decide..." > Also it is good to have more than one person read the mboxes, sometimes you > just > miss important points/words because you're braindead after reading too many > mails. If the FD doesn't have the power to decide whether to accept somebody or not, what is the point of it reviewing candidacies, specially if later the DAM will review it anyway? From an NM point of view, my feeling is: "I hope the Keyring Maintainers and the DSA don't feel like reviewing everything *again* to add my key to the keyring and to give me access to the developer machines" If there was just one body that reviewed that everything was OK, and then created all the required stuff, things would be so much smooth. And if you want more eyes, well, there already was the AM, but if more are needed, they could be another FD member. No need for 5 different teams IMHO. I hope that explains, Emilio signature.asc Description: OpenPGP digital signature
Re: DAM queues processing
On 23/06/09 at 14:29 +0200, Bernd Zeimetz wrote: > Stefano Zacchiroli wrote: > > I'd be perfectly fine with FD being the last review step, and DAM > > "just" in charge of creating the account, trusting FD judgement. > > > > What would we be missing that way? > > What you miss is that I move all problematic candidates to DAM with the > comment > "I'm not entirely happy, but its your job to decide..." > Also it is good to have more than one person read the mboxes, sometimes you > just > miss important points/words because you're braindead after reading too many > mails. If there are too many emails, maybe you should reduce the number of emails by reducing the number of questions asked? -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM queues processing
Stefano Zacchiroli wrote: > I'd be perfectly fine with FD being the last review step, and DAM > "just" in charge of creating the account, trusting FD judgement. > > What would we be missing that way? What you miss is that I move all problematic candidates to DAM with the comment "I'm not entirely happy, but its your job to decide..." Also it is good to have more than one person read the mboxes, sometimes you just miss important points/words because you're braindead after reading too many mails. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
DAM queues processing
On Tue, Jun 23, 2009 at 11:30:53AM +0200, Lucas Nussbaum wrote:
> Some of them have been FD-approved a very, very long time ago:
> Alexander Gerasiov has been FD-approved on 2009-01-10, and Asheesh
> Loria on 2008-12-22 (but apparently, because of an unanswered RC
> bug, DAM postponed approving him a month ago).
On Tue, Jun 23, 2009 at 12:06:29PM +0200, Bernd Zeimetz wrote:
> No way. Most reports show that a lot of NMs don't know about a lot
> of things asked during the NM process. This is true even for those
> who are DM already. And reading the AM report of those who obviously
> know what they're doing is not a problem at all. At least from my
> point of view (with my FD hat on) it takes *MUCH* more time to read
> trough a mbox of an applicant who is not able to answer all
> questions easily and who did not show in an obvious way that he will
> be a good DD with a good common knowledge.
This is all good and I'm very happy that you (as well as other FD team
members, I'm sure) review those mailboxes so thoroughly. The fact that
after that step, people can wait for 6 months for account creation is
the problem pointed out by Lucas and not addressed by your reply.
The question which is not answered is: why, after FD review, we should
wait for *another* review by DAM?
I'd be perfectly fine with FD being the last review step, and DAM
"just" in charge of creating the account, trusting FD judgement.
What would we be missing that way?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
