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

Re: Suggestion: Time limit for NM process



Pierre Habouzit <madcoder@debian.org> writes:

[...]
>  my (or not only mine, but I like them) ideas about that:
>
>   1) NM has to become a FIFO at each step: AM assigning, DAM
>      verification, ... because this is *predictable*. If someone does
>      not deserves to have an AM assigned or asks for time (because he
>      takes a trip over the world, or any other reason), those have to be
>      put in a side queue, or have a "frozen" attribute, that makes the
>      time they have spent in a particular queue be stopped (and of
>      course, queues have to be sorted by time passed in that queue).

It already works that way, just without an explicit "frozen" attribute.

>      That looks stupid, but for the guy who is there since 4 or 5
>      monthes, I can assure you it's not. I spent a whole month on the
>      last damn line of the « Applicants waiting for Front Desk
>      approval » step on [2]. And it was really a pain to see the queue
>      move forward, and see people that were in that step since less time
>      that I was go through. That contributes to the bad reputation of NM
>      queue a **LOT**.
>
>   2) we should ask NM's to show proofs of their work *before* having an
>      AM. I've heard many people speak of asking an applicant to be able
>      to show work they have done in debian. Packaging, work in a team,
>      whatever. E.g. I've heard proposals where applicant would be asked
>      to write a wiki page, with *links* that show their work (bugs
>      sorting, RC bug fixes, uploads, works with a sponsor, ...) with
>      links to the relevant BTS/PTS/Mail-lists posts/... entries.

The front desk already does these checks before assigning an applicant.

>      And a candidate that has not enough to show HAS TO BE PUT ON HOLD.
>      If the rule is clear, nobody will complain.
>
>   3) The full process is heavy for AM too. and afaict, if an AM has no
>      more time, or wants to step back, the NM he deal with can be slowed
>      down a LOT.
>
>      ==> I'd suggest that the whole NM process could use a special email
>      address, on @newmaint.debian.org for example, that put the mail
>      into a mbox that any AM can have access to. So that if a NM
>      complains about his AM beeing absent or too slow, everybody can
>      *look* at it, and know if the complain is legitimate.

The complaints are all pretty much legitimate.

>      this also easy the validating task more incremental, as each NM
>      could be followed by many persons. E.g. it would makes really sense
>      to have some read-only (viewable only by persons that are involved
>      with newmaint work) imap/nntp/... accounts, so that anybody could
>      check them when they have time, and eventually report problems even
>      before the DAM/FD has to review those applications.
>
>   4) thanks to 3, we could also involve sponsors and DD that work
>      regulary with some given NM to his NM-mailbox. If a DD sponsors
>      someone, given the time and involvment it represents (I sponsor 3
>      persons atm, so I know what I'm speaking of), it does not looks
>      that stupid to try to involve those in the application of their
>      pupil.
>
>      I'm not sure on what they could do, but I'm confident someone more
>      used to the NM process could have brilliant ideas about that.
>
>   5) I read Pascal Hakim's mail about what beeing DD means with big
>      interest. a short (~50-60 lines) mail should be sent to any
>      applicant, explaining that beeing a DD is a big responsability, and
>      that the NM queue is not about giving a reward, but about checking
>      that the applicant can handle that responsability well. So that
>      applicants that are too weak on some points can be sent back to
>      that text, and can't pretend they weren't informed in the first
>      place.
>
>      is that beeing elitist ? certainly. But I don't see any problems in
>      beeing elitist. If the process is readable, that the rules are
>      clear enough, and the results predictable, then nobody can
>      honnestly contest anything very long.
>
>   6) we should NEVER put any restrictions on time of any sorts. the
>      point 1) sets the rules: either you are the one that spent the most
>      time in that step, and you are the next to be processed, and thanks
>      to the wonderful work of FD, you know that will happen.
>
>      either you don't qualify, and you will be put on hold (with an
>      explanation) or freezed (on your own request).
>
>      I'd also suggest that candidates that are in "freeze" or on "hold"
>      at any stage could unfreeze/unhold themselves alone, that should
>      put them back in the queue where they belong (remember, one stage,
>      sorted by ascending time you spent in that stage, hold/freeze time
>      substracted). and if you abuse that (e.g. you un-hold yourself
>      without improving/solving the reason you were put on hold) that
>      could be a reason for expulsion from the NM queue, or putting back
>      at the stage 0 or ...
>
>      that's in fact a scheduling algorithm. It as a fairness property
>      that is vital for the sanity of the queue.
>
> Sorry for the very long mail.
>
> PS: I'd be really interested to work as an AM, and I've not found on
>     nm.d.o what I have to do to apply for that...
>
> [1] https://nm.debian.org/nmstatus.php?email=pierre.habouzit@m4x.org
> [2] https://nm.debian.org/nmlist.php
> -- 
> ·O·  Pierre Habouzit
> ··O                                                madcoder@debian.org
> OOO                                                http://www.madism.org

-- 
Captain Logic is not steering this tugboat.



Reply to: