Re: Reforming the NM process
Hi,
On Tue, 11 Apr 2006, Marc 'HE' Brockschmidt wrote:
> perhaps able to fix most of the problems. Please note that this is *my*
> opinion, not something decided by the NM team.
Thanks for starting this discussion !
> Quite a lot of applicants are frustrated by the NM process. The reason
> for this are mostly unresponsive AMs, waiting for AM assignment or
> waiting for FD/DAM approval. This has become worse in the past few
> months, mostly because our mailing list archives show applicants that
> they're not alone with their problems, but nearly nothing has been done
> to improve the situation.
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.
- 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").
(I would be perfectly happy if we only required the second point and
decided that the job of the AM is only to check that the applicant is
ready)
> 1.1.2 Application Managers
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> The lack of free Application Managers that led to the accumulation of
> applicants waiting for an AM is mostly based on the fact that many
> developers don't care about the NM process, so only a few people are
> actually helping out.
And also that you rarely ask for new AM on d-d-a and that the AM HOWTO is
difficult to find and outdated.
> 1.1.3 Front Desk
> ~~~~~~~~~~~~~~~~
>
> That one's easy. Brian has not much time, I'm bored by reading the same
> answers over and over and over again. Also, the amount of time I'm able
> to invest fluctuates, as my studies sometimes take up quite a lot of
> time (usually right before exams...)
The internal working of the NM team also lacks some transparency.
I understand the need of "privacy" on some issues, but that privacy
doesn't need to be restricted more than to Debian developers.
There are many different email whose use is not clear.
new-maintainer _AT_ debian.org
nm-committee _AT_ nm.debian.org
front-desk _AT_ nm.debian.org
I don't know what happen on nm-committee but for example I believe that
general discussion between AM on how to improve the system can happen on
debian-newmaint@l.d.o instead. (And Christoph Berg told me that such
discussion have been going on nm-committee since that's where he discussed
the possibility to use MIA scripts for NM)
Can you explain (quickly) the purpose of each email ?
> 1.2.1 Add more people
> ~~~~~~~~~~~~~~~~~~~~~
Change that into "recruiting more people" and then it becomes a solution.
People don't come alone ... :-)
(cf my previous point of asking for new AM while doing a nm.d.o report on
d-d-a)
> 1.2.2 Fewer checks
> ~~~~~~~~~~~~~~~~~~
This should be up to the AM, but as usual we should inform the AM of this
possibility.
> 1.2.3 Drop Front Desk/merge with DAM
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> The opinion that the FD check of reports is not needed has been
> presented more than once. Assuming this would be a real possibility, it
> would leave the problems not related to the DAM/FD unfixed.
Given that Joerg is really only doing "check of report" and giving the
final approval before James creates the account, yes it looks like work is
doubled.
FD is useful, but that final check is expensive given that Joerg (DAM
assistant) does it again.
> 1.2.5 More than one AM per applicant
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> In the recent past, people suggested to "share" applicants between a
> number of AMs, and/or assign a certain part of the questions to AMs who
> are experienced in that area. Looking at the current problems with AMs,
> this will not reduce the load, but add more load, as every one of the
> respective application managers needs to follow the application process
> to notice when he's needed. Also, we've experienced in the past that
> team work on boring tasks lead to a distribution of responsibility, to a
> degree that no one felt responsible. In conclusion, this may solve the
> problems applicants have with unresponsive AMs, but increases the load
> on the whole NM team.
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.
The best solution that I see is re-using a similar infrastructure than the
one used by MIA. Christoph Berg was ready to implement it (as I am).
> 1.2.6 Web-based checks
> ~~~~~~~~~~~~~~~~~~~~~~
No, definitely no.
> 2.1 Multiple advocates
> ----------------------
I have nothing against it but as Steve pointed we should also explain the
advocate how the NM process works and tell every DD that they should only
advocate someone that is ready. That's part of the "communication to
outside" that is a bit lacking right now with nm.d.o.
> 2.2 Requiring (more) work before applying
> -----------------------------------------
100% agreed. I would formalize this with the requirement to setup a wiki
page listing the contributions that one has made. And add a field to the
form used for registration on nm.d.o where the candidate must point to this
page.
> Implementing this could be helped by more clear requirements in the
> application form, together with a free-form text-field where
> applicants can explain what they're doing and what their plans are.
This information should be public, thus a simple URL pointing to a wiki
page looks more simple to implement.
> 2.3 Separate upload permissions, system accounts and voting rights
> ------------------------------------------------------------------
I think this is a sane move in the long term, but it has many implications
and those can be discussed in a new thread in response to aj's blog post.
Let's start by doing right now everything noted above.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: