Thijs Kinkhorst <kink@squirrelmail.org> writes:
> Thanks for this initiative; I'd just decided to not get involved in the
> threads on -newmaint anymore because even though I feel strongly about
> the issue, the threads were just a repeat of themselves. However, your
> mail seems to be different, in that it comes from someone actually
> involved and that it has some concrete plans.
>
>> 1.2.1 Add more people
>> 1.2.2 Fewer checks
>> 1.2.3 Drop Front Desk/merge with DAM
> I think these are still worthwhile to pursue, in the context of the
> other changes you propose below.
Sure. But they are only solving problems partially (or not even that),
so they're not useful as a real alternative to the other solutions. For
example, adding more people is something I'm working on, I've created 7
or 8 AM accounts in the last two weeks.
> Merging the FD with DAM is also an item I still support, since I think
> it saves effort, and I don't see any drawbacks in doing so: worst case
> it will cost just as much time as now, but with a simpler structure.
The DAM and FD have different tasks and look at reports from a
different point of view - while I mostly check for formal errors and try
to comment on things AM could do better in the future, Joerg has to
decide if an applicant is ready to become a DD. Though I sometimes
send a comment on the applicant to the DAMs, my decision can differ (and
does so from time to time).
>> 1.2.4 Task-based checks
>> ~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Some people, including me, have discussed the possibility to use a
>> task-based approach to the NM process. As far as I know, I'm the only AM
>> who has actually finished this with an applicant.
> I've actually done this with my AM, Luk, and I'm quite satisfied with
> this.
Ah, yeah. I'm reading the report right now (well, parts of it, piece by
piece...).
>> After doing this once, I'd not recommend it as a regular replacement for
>> the checks based NM templates we use at the moment, mostly because of
>> its time needs.
> I still would; it costs a bit more time, but that time actually yields
> results for Debian. This was more motivating for me, and it could be
> more rewarding for the AM.
Well, it's not really easy to find fitting tasks, especially for
applicants that are needing some hand-holding anyway. For those, this
could resolve in the AM investing more work than he would need to fix
the issue himself.
>> 2.3 Separate upload permissions, system accounts and voting rights
>>
>> This part is *very* experimental, I'd love to hear other people's
>> opinions, suggestions and changes. I'm really not convinced that this is
>> the perfect solution, but it has some very nice aspects.
> It is a bit of a generalization of the idea Anthony posted on his blog
> today. I like it.
Yeah, it's (as I said) stolen from aj. He proposes something a bit more
radical, which has some problems in my opinion. His proposal essentially
makes it impossible to sponsor people without giving them the permission
to upload on their own, which should IMO still be possible. Also, team
maintenance and similiar things become more complicated (well, that
depends on the final implementation).
I'd prefer to store the packages someone can upload in the userdir ldap
(putting "real" DDs in another Unix group) and generating something like
a configuration file for katie to list who's allowed to upload which
package.
Marc
--
Fachbegriffe der Informatik - Einfach erklärt (175: NT-Admin)
Turnschuhe, Schweissfüsse. Weiß, wo der Computer angeht und daß man
Probleme durch Neustart, Neuinstallation oder Neubelegung eines
4000-DM-Kurses in Unterschleißheim lösen kann. (Anders Henke)
Attachment:
pgpNX4k21ZS1J.pgp
Description: PGP signature