Uhh, I accidentally sent this before finishing it. Please ignore... Brian Nelson <[EMAIL PROTECTED]> writes:
> Pierre Habouzit <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] >> [2] https://nm.debian.org/nmlist.php >> -- >> ·O· Pierre Habouzit >> ··O [EMAIL PROTECTED] >> OOO http://www.madism.org > > -- > Captain Logic is not steering this tugboat. > -- Captain Logic is not steering this tugboat.
