Re: Reforming the NM process
[ Why the crosspost ? I responded only on -project since that where's Marc
pointed the mail followup to ]
On Wed, 12 Apr 2006, Joerg Jaspert wrote:
> On 10622 March 1977, Raphael Hertzog wrote:
>
> > And the bigger problem is that people who are ready to become DD may be
> > waiting on the AM assignation list while people who are not ready are
> > currently learning with the help of an AM whose job should not be to play
> > the sponsor of the applicant (unless he fully agrees with that).
>
> > The solution may involve two changes:
> > - ask each AM if she wants to process people who should be ready, or if she
> > accepts to take more time with applicants who are not ready but who can
> > learn with her.
>
> Then NMs see "Ah, if i say i know everything i can get an AM
> earlier". Nope, not good.
Why ? If the AM can check a wiki page listing all the contributions of the
applicants, he can quickly see if the applicant is ready or not. And put
it on hold and ask for a new applicant.
I don't want to change the way we prioritize people ... just to treat them
faster and leave the opportunity to the AM to say early, you're not yet
ready, please come back later.
Of course that early "rejection" can also be done by the front-desk (but
then we don't offer the possibility to the AM to play the trainer).
> > - first require each appliacnt to document their contribution when
> > registering on nm.debian.org. Then the FD checks if it's enough or
> > not. If not, he's immediately put on hold and the applicant can come
> > back a few months later (unless we have an AM who is willing to also
> > play as "trainer").
>
> Documenting stuff in a wiki-like page may help *a little bit* prior to
> the AM assignment, but not very much. And about nothing after that, as
> the AM already asks (if he uses my templates or something based on that)
> for the contributions, so another wiki page is useless there.
The response to the questions would be a pointer to the wiki (or a
copy/paste of it). I don't see the problem. The earlier we have that
information, the better it is.
> As if that would help, asking on d-d-a. Enough people get asked here and
> there (IRC, mail), most of them deny helping as AM. Lack of time, lack
> of interest, etc.
[...]
> >> 1.2.1 Add more people
> >> ~~~~~~~~~~~~~~~~~~~~~
> > Change that into "recruiting more people" and then it becomes a solution.
> > People don't come alone ... :-)
>
> How to "recruit" volunteers?
Just check the answer of Christoph Haas. He just said because he has no
library packaging skills, he feels that he can't be AM. This is wrong
because the FD assigns applicants based on skills/interests/etc, if that
information was more widely known, there's a chance to convince more DD to
become AM.
Of course, you're not sure that asking on d-d-a will bring many people,
but even one or two can do a big difference when you know that very good AM
can handle up to 15 applicants in parallel!
There's *nothing wrong* in asking and trying to find people.
> > nm-committee _AT_ nm.debian.org
>
> AMs that are active (finished an NM lately). Gets DAM-rejections CCed
> and could overturn it (except for ultimate rejections), for example.
Ok, handling rejections is a legitimate use.
> > front-desk _AT_ nm.debian.org
>
> That gets to the frontdesk members and to a archive mbox.
Can that archive be public to all DD? (If no, why?)
> > On this topic, I would really like that we setup a centralized system
> > which would not be mandatory but we that we strongly encourage to use.
>
> No, that wont work and is IMO one of the worst ideas, making it only
> more work and harder for the AMs to follow their NMs.
> I strongly discourage to use that.
Why is it harder to have the discussion as usual but to BCC a specific
adress (and bounce answers from the applicant there) ?
Then on merkel you have a mbox for each applicant with all the discussions
exactly as it happened.
If the applicant gets on hold and if another AM has to take over when he
comes back, he can easily check the history.
The infrastructure doesn't change anything in the way we're handling NM,
it just gives better transparency between the AM (and the DD) and it
facilitates the handover of an applicant to another AM.
> MIA can work very good this way because you dont need to remember much
> what was in the previous mails, and dont need too much context (except
> the usual "why and what"). You cant do that with NMs, where you have a
Huh ? The mbox stored on merkel for MIA is exactly for that, so that we
can find the history and the context with a simple mutt -f (or mia-query).
> (sometimes lengthy) discussion[1] with the NM, pointing out several flaws,
> where you need the context what he did say 3 or 4 mails ago. The
> MIA-style just works against that, as you, if you want to do it right,
> would need to read every prior mail of the NM and the other AM then,
> which greatly increases the load.
I expect most applicants would still be handled by a single AM. I don't
want to have several AM on the same applicant... I just want to facilitate
the transmission of applicant when an AM can't continue handling a given
candidate.
> Advocates already get a mail with the following text in it:
Right, you get it when you already agreed with the applicant that you're
going to advocate him ... it's difficult then to say "heh, wait I can't do
that for you, I've just been informed that X and Y".
Most of it is already done however:
http://www.debian.org/devel/join/nm-advocate
We just need to spread the word a bit further.
> Maybe the "encouraged" needs to be changed into a "must" and FD should
> control if the advocate had a good enough reason?
Yes.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: