This files contains the membership guidelines, and a small clarification issued by the board. The content comes from these two mails:
The clarification can be considered as a sum up of the 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 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." :-)  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 ;-).
Clarification of Membership
How inclusive does the foundation want to be. Is it sufficient to just use gnome libraries somehow ? To date we've required some level of contribution, from reporting a bug through to documenting or coding. '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.' The consensus is that these guidelines are sufficient. Just working on an application is _not_ sufficient. There needs to be some engagement with the community - filing a few bug reports - Community considers the application for inclusion somewhere in gnome (eg fifth toe)