NOTICE

This is a draft constitution, a living document, and not yet in effect. For now, consensus-based governance amongst all members is the rule.

Introduction

This document is a rough draft for a "constitution" for Galapagos. All operations in Galapagos shall be conducted in accordance with the contents of this document.

Intent

This document intends to create a framework for the distribution with the following aims:

• Allow for smooth operation of the distribution
• Enable efficient and fair conflict resolution
• Explain the rights of users and developers in the process
• Avoid the need to make things up on the spot
• Avoid becoming a bloated document prone to rule lawyering (and discouraging pettifogging)
• Procedures for amending this document

Goal

The distribution shall endeavour to uphold the following tenets:

• Quality packages that do not crash or misbehave
• Security issues are patched in a timely manner and are not swept under the rug
• Avoiding internal strife and drama, whilst respecting individual differences
• Respect for the opinion of users, with developers acting in the best interests of the distribution and the users
• Maintain a diverse and open distribution where anyone is welcome to assist

Structure

The organisation shall consist of its developers. The developers shall work to the common goal of furthering the distribution's aims.

Developer tenets

All the developers shall uphold the following tenets:

• Be respectful and courteous to other developers and users
• Be tolerant of the diversity of other members and users
• Avoid actions which bring disgrace, shame, or disrepute to the distribution
• Uphold the goals of the distribution

Primary governance

The primary governance of Galapagos is intended to be via consensus-based decision making. All decisions shall be made with the input of all stakeholders in the decision, until a consensus is reached for what to do. In the event a decision cannot be reached in a reasonable timeframe, the core council or arbitration panel may intervene.

Core council

The primary leadership shall consist of a core council of no fewer than 3 members, elected by single transferable vote by all members of the distribution. Core council elections are only considered valid if no fewer than 40% of developers in the distribution vote.

Core council elections are compulsory and shall take place over a period of 4 weeks every year. Elections with insufficient turnout may have a follow-up election with mandatory turnout under penalty of removal without a valid excuse.

Members of the core council shall not serve more than two total terms, consecutive or non-consecutive.

Members of the core council, or the whole core council, shall be subject to a recall election if ⅕ of developers successfully submit a signed petition to that effect (using PGP signatures), which must be held within 4 weeks of receiving the petition.

The recall election shall proceed as an ordinary election. The vacancy or vacancies shall be filled by the normal procedure for electing members of the core council.

The powers of the core council will be enumerated below.

Arbitration

An arbitration panel shall be formed, consisting of no fewer than 3 members, none of which may be members of the core council. The arbitration panel handles disputes within the distribution when moderation has failed, but may only act if the tenets of the distribution, developer tenets, or expectations of civil conduct have been broken in some way.

It shall have the power to suspend users (or issue partial suspensions like muting or temporary commit access revocation, or partial tree bans), issue warnings, and offer recommendations to resolve the conflict, but a user may not be suspended for longer than 30 days in any case. The arbitration panel shall also have the power to refer developers to the core council for possible expulsion, if they see proper.

The arbitration panel shall act in a preventative, not punitive, manner; that is to say, act in a way which causes the offending behaviour(s) to stop.

Arbitration panel members shall be appointed by majority vote of the core council, or elected by developers (at the candidate's option). Members may be removed by ⅗ vote of council or developers.

Users are entitled to arbitration against developers, and developers are entitled to arbitration against users. However, user to user disputes are outside the purview of the arbitration panel, except when they occur in official distribution forums. Punishments against users shall be limited to expulsion from distribution activities.

All meetings of the arbitration panel are to be conducted with a public audience (who may be muted). Both sides will have an opportunity to present their side of the dispute.

Members of the arbitration panel shall perform auxiliary duty as community moderators, encouraging developers to follow the distribution and developer tenets, and moderating discussions in a fair and balanced way.

The arbitration panel has the right to refuse to hear any case if they believe other forms of arbitration will work, or if arbitration is not required.

All decisions, regardless of disposition, or if the case was refused, may be appealed to the core council and overturned with a ⅗ vote, or appealed by general vote from all members.

Addition and removal of developers

Developers may be added by a ⅕ vote of the existing developer pool, or by a member of the core council acting as a sponsor. Developers may only be removed by council or developers with a ⅗ vote.

Addition of a developer

Prospective developers must meet the following criteria:

• Show technical competence with a simple examination in their area of interest
• Illustrate they can keep up with the demands of the area of interest they wish to join

Removal of a developer

Removing a developer shall only be performed if the developer does not uphold the tenets of the distribution, fails to be conducive in creating a friendly atmosphere, becomes permanently (or long-term) incapacitated, dies, or fails to perform duties for 6 months or longer.

Projects and groups

Developers may form groups or projects with specific goals. The following development projects shall exist:

• ebuild developers
• infrastructure management
• core council (a special case of group)

By default, all users are members of the ebuild development group unless otherwise specified.

Subgroups or subprojects may be created to serve specific aims, such as for Python ebuilds.

Projects shall be managed using consensus; members may be expelled from a project or group by ⅗ vote of all members, or forcibly removed by the core council or arbitration panel with a ⅗ vote.

Non-discrimination

No user or developer may be discriminated against for any grounds besides personal character. This includes (but is not limited to) race, religion, belief, creed, sex, gender identity, sexual orientation, disability, political affiliation, or sexual habits. Open bigotry shall not be tolerated and may result in expulsion.

Cases under said clause shall be handled by the arbitration panel.

Main tree operations

• (NOTE: this portion is provisional until a proper procedure a la GLEP's is created; this will then be located there)

The main tree consists of all the ebuilds in the distribution. They may be edited by anyone in the ebuild developer group. Maintainers shall adopt packages and be responsible for all bugs in the package. Other developers may modify the package, but must send courtesy notices to the developer in question unless a prior arrangement has been made. No developer shall have exclusive domain over their maintained packages.

At least once daily, a pull shall be made from the Gentoo main tree into Galapagos, with conflicting packages managed by their respective maintainers.

Groups may co-maintain packages, but there must be a responsible person for each package.

Infrastructure

Infrastructure shall be managed by the infrastructure project. All infrastructure operations are to be open to the public, except where sensitive information such as SSL keys are involved.

The infrastructure project shall carry out the wishes of council and developers, including adding and removing developers.

Amendments

This document may be amended by ⅘ majority of council or developer approval. Amendments may be proposed at any time.

Effect

This document shall not take effect until enough developers have assembled to approve it and bring the distribution organisation operational.

Interim governance will be provided by consensus decision-making.