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.
> - 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 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.
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.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
Frontdesk address. Forwarded to front-desk@nm.d.o
> 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.
> front-desk _AT_ nm.debian.org
That gets to the frontdesk members and to a archive mbox.
> 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 ... :-)
How to "recruit" volunteers?
>> 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.
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.
> 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).
No. That works for MIA, but i doubt it works for NM, and Im against
that, whatever that may be worth.
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
(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.
[1] For those who dont know the amount of mail a usual NM process gets
to: I had a report to read in the last days that would kill
around 80 *double-printed* pages. Usually they are between 25 and 35
double-printed pages. (Which makes it insane to print it).
>> 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.
Advocates already get a mail with the following text in it:
--8<------------------------schnipp------------------------->8---
Why do you advocate this person? (please provide a 5-10 line summary).
You are encouraged to take questions such as the following into account
but you're not limited to answering these:
- How have they contributed to Debian already?
- What do they intend to do for Debian in the future?
- How do they interact with others, such as users and other developers?
Please note that your answer may be cited on a public mailing list unless
you indicate otherwise.
This is an automated message from the Debian New Maintainer website.
Someone (possibly you) from the IP address " . getenv(REMOTE_ADDR) . "
nominated the Debian maintainer with the login \"$advocate\" as an advocate
for $forename $surname's application.
If you want to complete the advocacy process reply to this email, answer
the questions above and GPG sign it. Please also make sure to include the
Auth-Key (listed above) in your GPG signed reply.
If you do not want to advocate this application or do not know what it
means, just ignore this email.
--8<------------------------schnapp------------------------->8---
Maybe the "encouraged" needs to be changed into a "must" and FD should
control if the advocate had a good enough reason?
--
bye Joerg
SUSE = Soll Unix Sein, Eigentlich.
Attachment:
pgpcA198QyRlD.pgp
Description: PGP signature