Le Jeu 6 Avril 2006 06:11, Brian Nelson a écrit : > 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. I'm glad, then I suppose than make the web interface reflects those facts won't raise any objections then ? > > 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. uh, I believe you, but that was really unclear to me. If the applicant has a page on which he puts all the work he did/do/... I really think that could help FD anyway, it helps them to avoid looking for informations. And if there is no to look for, then the wiki page would be blank, and the candidate delayed. > > ==> 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. okay, so we agree on that. > > 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. well I suppose it's the same for every AM. But splitting the questions in many pieces would just make things work, because you'll need to contact many different people... which will slow down the average cases, and makes the border cases even worse. That's why I'm more in favor of a process where all is public (in a restricted circle or not, actually I don't care, it's just that when an applicant is not good, you don't want his application where he got eventually bashed find-able on google, here was the reason of my hesitation), so that the process is easy to reassign to someone else in case of too much sleep on one end or the other. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpShsR0l0rGw.pgp
Description: PGP signature