Re: Fwd: Proposal.



On Fri, 2002-10-11 at 10:39, Telsa Gwynne wrote:
This is the proposal Nat wrote and mailed to board-list earlier
this week. We haven't actually achieved a consensus on this yet :) 

Thank you Telsa for forwarding the proposal.

It looks like we'll have (yet) another meeting where we want to
have a resolution at the end of it. This is likely to be early
next week. 

If you have comments on the implementability (is this a word?)
of either the current guidelines for looking at applications or
this proposal of guidelines, please do respond in as much detail
as you want.

One thing which might be particularly helpful is specific
examples of problems you've met already and what the result
was. (Whether the result would have differed with these would
also be worth noting.)

Telsa
----- Forwarded message from Nat Friedman <nat ximian com> -----

Delivered-To: board-list gnome org
X-Authentication-Warning: lamarck.ximian.com: nat set sender to nat ximian com using -f
Subject: Proposal.
From: Nat Friedman <nat ximian com>
To: board-list gnome org
Organization: 
X-Mailer: Ximian Evolution 1.1.1 (Preview Release)
Errors-To: board-list-admin gnome org
X-BeenThere: board-list gnome org
X-Loop: board-list gnome org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Help: <mailto:board-list-request gnome org?subject=help>
List-Post: <mailto:board-list gnome org>
List-Subscribe: <http://mail.gnome.org/mailman/listinfo/board-list>,
      <mailto:board-list-request gnome org?subject=subscribe>
List-Id: <board-list.gnome.org>
List-Unsubscribe: <http://mail.gnome.org/mailman/listinfo/board-list>,
      <mailto:board-list-request gnome org?subject=unsubscribe>
List-Archive: <http://mail.gnome.org/mailman/private/board-list/>
Date: 08 Oct 2002 15:04:30 -0400

       Proposal for GNOME Foundation Membership Guidelines

Definition
----------

    For the purposes of this proposal, I am talking about the
    membership as defined by the GNOME Foundation charter.  The
    charter (http://foundation.gnome.org/charter.html) defines a
    member as a person who can run for the GNOME Foundation board,
    vote in board elections, and issue or endorse a referendum.

    This definition is to distinguish what I'm talking about from the
    various ideas people have put forth for several classes of
    membership, e.g. "membership," "lifetime membership," "gnome
    friend," etc.  I'm not proposing or discussing a multiclass
    system, only talking about the voting membership as defined by the
    charter (not including the guidelines for membership defined in
    the charter, since those are the things we are discussing and
    trying to agree on).

You propose only one class of membership, but later on you differentiate
between a lifetime membership and an annual membership.  I believe there
are two types of people we are talking about.  The first are
contributors who are currently contributing code, documentation,
translations, bug fixes, etc.  The second group of people are those who
have made these contributions in the past, but are not currently
contributing to the GNOME project right now.  This definition is very
misleading because there those two groups of people who are requesting
membership.  For the remainder of my reply I will talk about current
contributors as the first group of people and past contributors as the
second group of people.
 
Proposal
--------

    1. Definitions

    A member of the GNOME Foundation is someone who can run for the
    GNOME Foundation board, vote in board elections and issue or
    endorse a popular referendum.

    Membership in the GNOME Foundation is controlled by a Membership
    Committee who process applications from individuals who wish to
    become members.  This committee is responsible for accepting and
    rejecting applications based on membership guidelines set by the
    Foundation board.

The membership guidelines are not set exclusively by the board.  A
referendum to change the guidelines made by the general membership body
can be added to the bylaws of the GNOME Foundation.
 
    2. Guidelines for Membership

    Any person who has made non-trivial contributions to the GNOME
    project and who submits a proper application to the Membership
    Committee will be approved for membership.  A non-trivial
    contribution is any activity which contributes to the development
    of the project at a level significantly above that expected of a
    normal user or fan of GNOME.

    Examples of non-trivial contributions include hacking, bugfixing,
    extensive testing, design, documentation, translation,
    administration or maintenance of project-wide resources, giving
    GNOME talks at conferences and community coordination such as
    bugzilla or release management.  Any activity, such as advocacy or
    submitting bug reports, must substantially exceed the level of
    contribution expected of an ordinary user or fan of the project to
    qualify an individual for membership in the Foundation.

This is the main part of the guidelines I would like to see expanded
upon.  The word "non-trivial" is the whole crux of the matter.  Is a
non-trivial contribution providing a hack which is taken out in 30 days
or editing a document or translating 5 strings?  I do not think we
should define what a trivial contribution consists of, but general
guidelines from the board would prove very useful.  That is one of the
many questions the committee asks itself when it approves or rejects an
application.

Another part of the guidelines I believe should be expanded is the
substantial level of contribution for other GNOME related things.  Is
attending GUADEC enough to become a member or is helping at a conference
a substantial contribution?  This is another part of the guidelines the
membership committee has struggled with especially when some of us have
never gone to a GNOME conference.  The only way to check up on the
people is through email and if the references do not explain what the
applicant has done well then the applicant is probably be denied
membership even if they have made a substantial contribution.


 
    3. Membership Duration and Renewal

    Membership in the Foundation is lifetime.  However, in order for a
    membership to be valid, it must be renewed every year.  The intent
    of this renewal process is to ensure that the membership roster is
    not filled with people who no longer have any interest in the
    project, and to verify and keep up-to-date membership contact
    information.

    To renew his membership, an individual must submit a new
    application for membership.  If the application is well-formed and
    the individual has previously been a member of the Foundation, his
    membership will be automatically approved.  All renewals will take
    place at once, every year.

Right now there are logistical concerns with an annual membership.  We
do not have the man power to investigate each applicant thoroughly once
a year.  Also the applications are grouped around the elections.  This
splits our man power between processing applications and planning for
the election.  I like how the membership is every two years.  This will
allow the membership committee to thoroughly examine the applications
and renewals.  A two year membership will also allow the membership
committee to put all our man power behind planning and running an
election instead of splitting our man power between processing
applications and running an election.

Rationale
---------

    * Intent and Effect of Membership

        - Intent: govern the Foundation.

            The intent of the membership is to provide a governing
            body for the GNOME Foundation that has ultimate
            responsibility for directing the Foundation's resources.
            The powers of this governing body are to elect the board,
            run for the board, and to issue and endorse referenda.

        - Effect: sense of inclusion in the GNOME project.

            The membership intent, stated above, is the only explicit
            reason for the membership's existence.  But membership in
            the Foundation, and the candidacy and voting rights it
            entails, has another effect which is important to this
            discussion.

            Specifically, non-membership in the Foundation, in the
            form of a rejected application, can create a sense of
            alienation or exclusion from GNOME.  People will always
            approximately equate the rights of membership with
            membership in the GNOME project, not just the foundation.

    * Guidelines for membership.

        The membership guidelines outlined above are intended to be as
        open as possible, to include everyone who has contributed in a
        non-trivial way before and everyone who is contributing now.

        The general idea of inclusiveness is something I talked about
        a lot (and in retrospect, in embarrassingly florid ways) in
        the Foundation charter.  You should go back and read the
        charter (http://foundation.gnome.org/charter.html) if you
        haven't read it recently, since I articulated a lot of the
        ideas behind the openness of the foundation there.  Back then,
        some of the motivation was figuring out how to deal with
        corporate entities getting involved in GNOME, and I think
        those arguments are still somewhat valid, but there are
        broader reasons too.

        I would also remind everyone, as a backdrop to listing the
        Pros and Cons of the proposed policy, of the relative costs
        and benefits of a "false positive" versus a "false negative"
        in the application approval process.  

        A false positive means that we have people in the voting body
        who have not contributed significantly to GNOME.  In the worst
        case, these people will vote for the wrong board members, or
        be annoying in other ways.  We should have a mechanism for
        handling truly egregious members (though I can't think of
        anything really awful an individual member can do right now),
        but in general the ill effect of allowing someone into the
        foundation who has not contributed is that they might vote in
        an uninformed way.

        We should do our best not to have members who have done
        nothing for GNOME, but the relative ill effects of refusing
        someone who has never been very involved in the project is
        that they might vote spuriously in the lection.  On the other
        hand, there is a positive effect of accepting "borderline"
        applications, which is that the applicant will feel more
        involved in the project overall, and might contribute more.

There is one concern with accepting "borderline" applications.  The
membership should be actively carrying out its duties for existence,
mainly electing the board to run the foundation and passing referendum. 
Currently I believe the current membership is not carrying out its
duties.  There have been no referendum passed in the existence of the
foundation.  The member turn out for the board elections was below 50%. 
I was proud to vote in the elections of the foundation, but a lot of
members did not wish to participate in the only function of membership.

I would like to propose any member who has not voted in the past 4 years
be automatically rejected for membership and can apply for membership
the following year.  The rationale behind this is the sole existence of
membership is to vote for the board.  If a member has not voted in 4
previous elections then they are not wishing to be a part of the
foundation.  Replying to an email each year is rather easy to do.  True
desire to contribute will result in the member making a difficult
decision and voting in at least one election every 4 years.  I believe
this will effectively weed out the false positives that may be
introduced by a more inclusive membership guideline while not adversely
introducing false negatives.

 
        A false negative means that a person who is a substantial
        present or past contributor to GNOME and who has expressed an
        interest in being a member of the foundation through his
        application was rejected by the membership committee.
        Rejecting this person doesn't just mean that a contributor who
        was eligible for membership will not be in the membership: it
        means a contributor who was eligible for membership and who
        *wanted to be a member* was rejected.

        The cost of this is high: it creates bad feelings in the
        project, it creates a sense of elitism, and it alienates a
        contributor whose lack of voice in the foundation affairs will
        frustrate him.

Yes, I agree the new membership guidelines should be written to reduce
the number of false negatives to almost zero while eliminating the false
positives over time.  However, I do not believe inclusive membership
guidelines will reduce the number if false positives.  Therefore I
believe two measures should be taken to insure the number of false
positives will decrease over time.  The first step is already being
taken which is to only accept complete renewals for membership.  The
contributor needs to show the willingness to become a member of the
foundation before they should be accepted.  The second step is to ensure
the membership votes at least once for every x number of years.  The
member needs to show a continued willingness to be a part of the
foundation instead of just saying they are a member and never exercising
their privileges as a member.  These two things will help ensure the
false positives are weeded out over time so the membership accurately
represents the GNOME community.
 
I believe there needs to be a mechanism to weed out the false positives
a policy of total inclusiveness brings to the membership at large.  I
believe the things stated will help to reduce the number of false
positives.  I also believe an annual membership will place too much of a
strain on the membership committee and believe there are other ways to
eliminate the false positives besides having the entire membership
reapplying every year.

Eric Baudais




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]