[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.  But yes, it would be
very nice if AMs weren't so isolated from each other.

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

I'd tend to doubt many AMs would follow another's applicant that
closely.

I think a better approach to NM in general would be, instead of having
one AM per applicant with the AM processing the entire application,
split up the work among multiple AMs.  For example, each AM would
process the same set of 5 or so questions for each applicant.
Preferably, these questions would be in the area that the AM was most
interested in.

This would improve consistency across reports as well as improve
responsiveness of the whole process.  It's a lot easier and quicker for
both AMs and applicants to process a small set of questions than the
giant sets we currently use.

It would also hopefully keep AM's more interested in the work.  I know
for myself, there are lots of questions in the NM tests that I find
really tedious to process.  I would much prefer to only handle a few of
the questions I like.

-- 
Captain Logic is not steering this tugboat.



Reply to: