On Fri, 2008-09-05 at 15:55 -0700, Edward Cherlin wrote: > Please add your thoughts on members' rights and duties. Showing up at > meetings, in person or online? Voting? If so, on what? Who qualifies > for a title and an e-mail address? Discounts on anything of interest, > such as Sugar Labs events? A t-shirt?
I am thinking that as we agree on the 3 principles, determine the relative weights of the purposes, and discuss the various structures, the right's and responsibilities will start to sort themselves out. > How do you propose to choose among these possibilities for a > structure, or any others that may be proposed? Spend the next few weeks discussing the issues. Work with the Membership committee to propose a draft. Submit the draft document to flossfoundations.org and the linuxfoundation for feedback. Submit the final document to the Oversight boards for conses. > On Fri, Sep 5, 2008 at 3:25 PM, David Farning <[EMAIL PROTECTED]> wrote: > > When setting up the membership structure for Sugar Labs we have several > > issues to consider. Below is a brief analysis of those issues and how > > they relate to sugar Labs. Feed back on issues I have missed or > > misunderstood is appreciated. Monday I will post an initial Membership > > document to the wiki and this list for more review > > > > > > Principles of Membership > > > > > > One way to define the 'spirit' of membership is to explicitly define > > membership principles. > > > > Open – Sugar Labs is open to all; Sugar Labs provides the same > > opportunity to all. Everyone participates with the same rules; there are > > no rules to exclude any potential contributors which include, of course, > > direct competitors in the marketplace. > > > > Transparent - Project discussions, minutes, deliberations, project > > plans, plans for new features, and other artifacts are open, public, and > > easily accessible. > > > > Meritocracy – Sugar Labs is a meritocracy. The more you contribute the > > more responsibility you will earn. Leadership roles in Sugar Labs are > > also merit-based and earned by peer acclaim. > > > > > > Purposes of membership > > > > > > Keeping track of membership will be costly. There is the initial setup > > costs and the ongoing maintenance cost of keeping the membership roles > > up to date. These cost must be out weighed by the benefits of > > Governance, Recognition of Merit, Fund Raising, and Defense. > > > > > > Governance. - On the first level a membership body give Sugar Labs the > > ability govern itself. Member will be able to vote directly on issues. > > Members will be able to vote for elected representatives. Member will be > > able to call referendums. > > > > > > Recognition of Merit – Individual membership in will be a sign of Merit. > > Membership, responsibility, and authority will reflect the value of an > > individuals contributions. > > > > > > Fund Raising - Organizational membership will indicate levels of support > > Sugar Labs receives from outside entities. Support can include cash, > > engineering resources, event and travel sponsorship. > > > > > > Defensive – Broad definitions of membership will help prevent the Sugar > > Labs foundation from being hijacked by a hostile entity. > > > > > > > > Membership types > > > > > > Individual – Most projects have a category for individual membership. > > Membership is earned through quality of work. > > > > > > Organizational – Some projects have categories for organizational > > memberships. The fee structure for Organization membership can vary > > based on the size of the organization and the degree of influence the > > organization has over the Project. > > > > > > > > Membership Documents > > > > > > In order to keep track of members and their contributions we will need a > > basic set of documents. > > > > > > Application – The membership application will ensure that Sugar Labs has > > at a minimum the real name and contact information for members. > > > > Code of Conduct – The code of conduct will establish a set of principles > > and expectations for Sugar Labs Members. > > > > > > > > Membership structures > > > > > > Now that we have defined why we want a membership we need to chose a > > membership structure that reflects our needs. Below are some categories > > of Membership, projects using them, and pros and cons to their use. > > > > > > None – One of the most successful foss projects has no formal membership > > criteria. The closest thing the Linux Kernel has to a membership list is > > who receives an invitation to OLS. Pros: Very cheap. Cons: Requires a > > dictator to govern the project. > > > > > > Twin – RedHat/Fedora, Ubuntu/Canonical, Open Office/Sun are examples of > > tight couplings between community projects and specif commercial > > entities. In twins, the commercial entity provides resources to the > > community in exchange for community involvement. Pros: Form the basis > > for sound business models. Limited fund raising required by the > > community. Cons: Possible tensions between the needs of the community > > vs. the needs of the corporation. > > > > > > Stand alone – Gnome is an example of a stand alone project. They are not > > aligned with any single entity. In stand alone projects, the members can > > have differing levels of control over their project. Sometimes members > > can affect technical decision, other times a separate group of commiters > > make technical decisions while the membership governs the infrastructure > > needs of the project. Commercial entities can have membership status. > > Pros: The most common form of membership. Well understood. Cons: There > > is no 'vision' provided by the twin, the membership must determine the > > projects direction internally. Requires fund raising. > > > > > > Umbrella – Apache is an example of an Umbrella organization. Umbrellas > > tend to form when there are a number of closely related projects that > > share a common goal. They introduce and additional level of management > > as the individual projects are governed independently. The umbrella > > organization can play an active role in individual projects or it can > > focus on providing the infrastructure of sub project. Pros: Good for > > establishing ecosystem. Cons: Can be complex. > > > > > > Space Shuttle – Eclipse is an example of a space shuttle project. It is > > so complicated that it is amazing it gets off the ground;) On the other > > hand, it was designed to handle some hostile situations. Eclipse > > provides a common standard and platform for competitors to collaborate. > > > > > > _______________________________________________ > > IAEP -- It's An Education Project (not a laptop project!) > > [email protected] > > http://lists.sugarlabs.org/listinfo/iaep > > > dfarning _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
