[IAEP] membership definitions

Sameer Verma sverma at sfsu.edu
Tue Sep 9 11:19:13 EDT 2008

On Mon, Sep 8, 2008 at 6:08 PM, Greg Dekoenigsberg <gdk at redhat.com> wrote:
> On Mon, 8 Sep 2008, Polychronis Ypodimatopoulos wrote:
>> Greg Dekoenigsberg wrote:
>>> Yes... but why build a complicated membership management structure to do
>>> that?
>>> There's a reason I'm asking.  Keeping track of who is and isn't a "member"
>>> can turn out to be surprisingly acrimonious and political, and will take
>>> more overhead to properly manage.
>>> IMHO, there's little reason not to extend some privileges to basically
>>> whomever asks.  Email address?  Sure.  Logo usage, within clearly
>>> circumscribed guidelines?  Sure!
>> Your suggestion resonates well with me. What is the model that existing
>> organization follow, such as Fedora, Debian, etc.?
>>> Voting for the board?  Sure!
>> I'm not really sure about this. Maybe you need to be involved in the project
>> for some time until you get a vote. Say, you can have a voting right <some
>> arbitrary number of months> after your application -during which time you
>> will have all the above that you mentioned-.
> In the latest Fedora board election, we had about 10% of our entire
> membership vote.  It's really easy to get lost in the vagaries of voting,
> but in my experience, most people just aren't going to be that interested.
> I mean, what's the fear?  That a bunch of M$ employees will storm the
> membership system, take control of numbers, and vote in a bunch of free
> software hating stooges?  Having a SABDFL can help mitigate this.  Give
> Walter a Big Hammer, with the understanding that he will only use it
> during the most extreme circumstances.
> --g
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep

I agree with Greg. Keep the membership as open as possible (default
ACCEPT) and have effective mechanisms to DENY if necessary in case
someone becomes troublesome or subversive. The overhead with periodic
assessment will take time and focus away from the project.

Dr. Sameer Verma, Ph.D.
Associate Professor of Information Systems
San Francisco State University
San Francisco CA 94132 USA

More information about the IAEP mailing list