On Sat, 2004-10-02 at 11:02, Nadim Shaikli wrote: > --- Muhammad Alkarouri <malkarouri at yahoo dot co dot uk> wrote: > > The systematic solutions you are seeking are either: > > - Using my suggestion, which is your system (6run12vote) plus a simple > > ban list (could be a text file) which is generated manually and observed > > by the voting system, the candidates being already generated by the > > system (active cvs accounts), or > > - Deciding on arbitraty complex rules to judge. 6R12V and the person > > should be X and hasn't been Y since Z and is within the bounds of W, > > etc. > > The crux of our "fears" is that an unknown entity (or multiples there-of) > get CVS access under the pretext of doing work, do a couple of superficial > commits (of no or little value) and they are granted full voter access > given this all happened within the past 12months. Along the same lines > of a "ban list", we could have a probation period for all new incoming > CVS account holders. That probation is only lifted if their project-manager > (ie. whomever they are helping) or a 'core' member if they've started their > own project OK's them within a certain period of time. This in turn gives > Arabeyes a level of comfort in knowing that all those that will vote are > genuine bona fide contributers who truly should have an equal say in what > is to occur (plus all of this can be scripted :-). > Not really an issue. I am not giving out CVS accounts unless the project maintainer of a given project actually okays the account. Until then, the contributor can submit patches via bugzilla [1]. Makes everyone's life easier. [1] http://bugs.arabeyes.org/ -- Regards ------------------------------------------------------- | Mohammed Elzubeir | Visit us at: | | | http://www.arabeyes.org/ | | Arabeyes Project | Homepage: | | Unix the 'right' way | http://elzubeir.openius.com/| -------------------------------------------------------
Attachment:
signature.asc
Description: This is a digitally signed message part