GNOME Foundation membership guidelines.



Hi guys,

Today, after a couple weeks of long discussions among the board members
and with the membership committee, and with people affected by the
recent membership application decisions, the board voted to approve a
new set of proposed membership guidelines.  In particular, we felt that
people who had contributed to the project were being unfairly rejected,
and came to the conclusion that the foundation membership should be
fairly open.

The membership committee (which I don't represent, but this is what I
hear) will be operating under these new guidelines starting today.  All
rejected applications from the recent round of membership submissions
will be reviewed under the new guidelines.  This will happen in the next
couple weeks, in preparation for the upcoming board member elections
later this year.

The guidelines that are attached were written by me; it should be said
that we did not end up with unanimous agreement by the board on these
guidelines, but we felt that approving these was the best way to move
forward.  As further problems arise - they always do - we'll work hard
to help the membership committee resolve them more quickly and more
smoothly than happened in this case.

Okay for now.  Please address questions about the process to the
membership committee, membership-committee gnome org 

Best wishes,
Nat
	 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).

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.

    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.

    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.

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.

        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.

    * Pros and Cons of being inclusive.

        Below, I discuss the Pros and Cons of a policy which embraces
        inclusiveness.  For the Pros, I outline various arguments for
        this inclusiveness.  For the Cons, I articulate the arguments
        (that I have heard) against inclusiveness and respond to them.

        Pros of Inclusiveness
        ---------------------

            - Rejecting contributors is bad.

              The current crisis of the membership committee began
              because the current membership guidelines caused the
              membership committee to reject people who had
              contributed or who were contributing to the project.

              The cost of these rejections is that the rejected
              contributors feel alienated from GNOME, they feel that
              their contributions are not valued, and they are less
              likely to contribute in the future.  This also creates
              tension, a sense of elitism or cliquishness in GNOME,
              and feelings of ill will and hostility.

            - Recognizing the contributions of contributors.    

              Most people who get involved in GNOME start off with
              small contributions of bugfixes, code, translations or
              documentation.  Recognizing the contributions of these
              people can give them a sense of inclusion in the project
              and can encourage them to continue to work on GNOME, and
              to grow into large contributors to the project.

            - GNOME is a cumulative project, and the membership should
              be cumulative too.

              When a person puts a lot of time and energy into
              contributing to the project, the project should
              recognize this time and energy by giving that person the
              rights of a Foundation member.  

              If a person is a past contributor, but not a present
              one, and still wants to be active and involved in the
              project and demonstrates this by applying for a renewal
              of his membership, then he should continue to be a
              member of the foundation.

              The GNOME contributor base is always changing, as new
              people become active and involved and older long-time
              contributors move on to do other things.  However,
              having a membership which is just made up of the new,
              fresh contributors and a few long-time hackers who
              continue to be involved silences the voices of those
              people who have accumulated experience, knowledge and
              understanding through their involvement with the
              project.  

              We should not ignore or exclude the voices of those
              people who have helped us in the past.  The GNOME
              project is continually building on past work to create
              something better, and the membership should build
              accordingly.

            - Continued membership encourages people to stay involved.

              Just because someone has dropped out of the project for
              a little while does not mean that they will never come
              back and help again.  And particularly, if someone has
              dropped out for a while, but *still applies for a
              renewal of his membership*, then he is clearly someone
              who wants to stay involved and may begin to contribute
              in the future.  People who don't want to be involved
              again will not apply for renewal.

              Rejecting the renewal application of a past contributor
              is an effective way of telling them that they are no
              longer considered a part of the foundation and the
              project, even though they want to be.

        Cons of Inclusiveness
        ---------------------

            - Past contributors will outweigh present contributors in
              the foundation elections and vote for the wrong people.

              There are two misapprehensions in this argument.

              Misapprehension #1: there will be more past contributors
              than present contributors.

              First, we already have two mechanisms for culling the
              voting membership: (1) an annual renewal which a member
              uses to express his interest in continuing to belong to
              the foundation, and in demonstrating that he is keeping
              up with the project on an ongoing basis; (2) a voting
              process which does not require that 100% of the
              membership vote.  

              Many past contributors who are no longer interested and
              involved, and who do not take the time to keep up with
              the project, will either not renew their applications or
              will not vote in the elections.  This will effectively
              weed out the people who are not keeping up with the
              project, and the effect of their membership on the
              voting process will be minimalized.

              Second, if GNOME is successful, it is growing fast
              enough that new contributors will be significantly and
              proportionally recognized in the membership.  As new
              large projects like Galeon, GStreamer, Gaim and Anjuta
              join the GNOME effort, the contributors to those
              projects will be eligible for membership in GNOME and
              will add substantially[1] to the membership.

              Misapprehension #2: Past contributors will vote for the
              wrong people, and upset current contributors.

              Past contributors have the benefits of their experience,
              and this experience will inform the election process,
              lending acquired knowledge and wisdom, as well as
              continuity, to the governance of the GNOME Foundation.
              
              It is not at all clear that a group of past contributors
              will vote for the wrong people, even if they had 100%
              control over the voting process.

            - The membership list will get too big to handle.

              Not committing the time to process the applications of
              people who want their voice heard in the GNOME
              foundation, and who want to feel included in the
              project, is a terrible reason to add further controls
              and constraints to the membership criteria.  We should
              be accepting or rejecting people based on whether or not
              they should be members of the foundation, not based on
              whether we have the time to deal with them and their
              applications.

              If the membership committee is overwhelmed, then we
              should take steps to find the resources to help them.

            - A smaller percentage of the total membership will vote
              in the foundation elections each year.

              Remember that the only people eligible to vote each year
              are the people who took the time to renew their
              applications.  This may still lead to a less-than-80%
              voting population (no doubt it will), but this is
              actually useful, because it serves to cull from the
              voting body the people who are not, at that particular
              time, tracking the project and the foundation.

            - Inactive past contributors don't deserve to vote, since
              they're not contributing anymore.

              Think of a person's contribution to GNOME as an
              investment in the project.  If GNOME is succesful, then
              we will find ways to encourage and welcome many many
              different investments into the project.  In recognition
              of these investments, and to encourage them, we will
              give people membership in the foundation.  As new
              members come on board, the relative weight of each
              member vote will be decreased.  That is, past
              contributors will have their vote diluted by new
              members.

              A group of old members will be able to represent their
              opinions, based on their experiences and the things
              they've learned working with the project, with a voting
              power proportional to their overall contribution to
              GNOME.  And the project will benefit from not making the
              same mistakes again and again, because the older, wiser
              voices will be there to guide us.

Wrap-up
-------

    The proposede guidelines above probably could be tweaked a bit,
    but the main thing I am trying to get across is the importance of
    (a) inclusiveness in the application review process, and (b)
    lifetime memberships.

    At least, I don't know of any compelling arguments against these
    things, and we have seen firsthand negative effects when you try
    to be too exclusive or to time-limit memberships.

    When you reply to this mail, please try to reply to the individual
    issues separately.  For reference, these issues are:

        1) Membership process and mechanism (application, renewal, ...)

        2) Inclusiveness of membership guidelines vs exclusiveness of
           membership guidelines.

        3) Lifetime vs time-limited membership.

    Hopefully everyone will just say "this is great, I agree." :-)

[1] If we're lucky we'll grow exponentially, like the human
population.  If so, then at a certain point there will be many more
people contributing at any given time than ever contributed before.
See http://nat.org/population for more information ;-).


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