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

Re: Suggestion: Time limit for NM process



Uhh, I accidentally sent this before finishing it.  Please ignore...

Brian Nelson <pyro@debian.org> writes:

> 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.
>

-- 
Captain Logic is not steering this tugboat.



Reply to: