From 0515cf1fd9fd0c7898a8d383490d658bf5c96024 Mon Sep 17 00:00:00 2001 From: "A. Wilcox" Date: Thu, 13 Jun 2019 13:24:28 -0500 Subject: charters: Rename file to note it is Charter 0001 --- src/charters/0001-org.rst | 214 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 214 insertions(+) create mode 100644 src/charters/0001-org.rst (limited to 'src/charters/0001-org.rst') diff --git a/src/charters/0001-org.rst b/src/charters/0001-org.rst new file mode 100644 index 0000000..9e431cb --- /dev/null +++ b/src/charters/0001-org.rst @@ -0,0 +1,214 @@ +=============================================== + Project Organisation Charter for Adélie Linux +=============================================== +:Authors: + * **A. Wilcox** +:Status: + Draft; RFC +:Copyright: + © 2019 Adélie Linux Team. CC BY-NC-ND-SA 4.0. + + + +Introduction +============ + +Adélie Linux is growing and maturing into a full-featured Linux distribution +with many individual contributors, goals, and directions of growth. The +Platform Group, serving as the core contributors of the project, desire an +organisational structure that serves the needs of the community. This +structure shall ensure that people who are new to the community can easily +contribute to the project. This structure shall additionally ensure that our +community's goals can be accomplished swiftly and with proper documentation. + +Adding too much formality to this organisational structure could cause undue +delays and pressure on the community, and could stifle innovation and +creativity. Therefore, most of the structure that this charter proposes is +rooted in the processes that Adélie has already organically grown. We feel +that defining these processes, and refining them into even better processes, is +the best way forward for our community. + +For the purposes of this document, a Committer is a contributor to Adélie Linux +whom has write access to at least one official Adélie Linux Git repository. +The process in which Committers are inaugerated into Adélie Linux is described +in a separate Charter. + + + +Projects +======== + +Our first act in this charter is to define "Projects". A Project is a +collective of contributors working towards a common goal. This goal should be +on-going and clearly defined (see Interest Groups below for one-time tasks). +At least one Committer is required to form a Project. + +All Projects will be assigned a mailing list address, typically adelie-$project +where $project is a unique, short name for the Project. + +Projects will be granted a Web space for any documentation they feel +appropriate. All Projects will be required to maintain a list of Committers +involved in the Project on this Web space. Projects may additionally maintain +a list of frequent non-Committer contributors as well, but they are not +required to do so. + +A Project that relates to packages will have an official designated branch of +packages.git. Non-Committer contributors will create merge requests to this +branch, to be reviewed by a Committer in the Project. Committers in the +Project may either create merge requests to this branch, or commit directly to +this branch. A Project may be listed as the maintainer of any package that is +relevant to it. + +Periodically, it is expected that the Project will want to merge its changes in +to the main Adélie Linux system. This will be accomplished by the Project +opening a merge request to the `master` branch, which will be reviewed by at +least one member of the Platform Group. + + +Creating a Project +------------------ + +A Project may be proposed for creation at any time by a Committer, via sending +an email to the adelie-project@ mailing list. This proposal must be approved +by a simple majority of the Platform Group. + +The Project proposal must contain the name of the project, the desired short +name for the mailing list, and the common goal it wishes to achieve. + +The proposal for a new Project may contain an initial list of members. If so, +each member is expected to respond to the message on the adelie-project@ +mailing list with an ACK. If they do not respond to the message within 48 +hours, they will not be added to the initial roster of members of the Project. + + +Joining and Leaving a Project +----------------------------- + +Projects may describe their own processes for joining and leaving their +respective Project. + +The default process, if a Project does not describe their own, is that any +Committer in a Project may nominate any member of the community to join the +Project. The community member then ACKs this using the Project's preferred +communication medium; either mailing list or IRC channel. If no other +Committer is present in the Project, the member is then added; otherwise, at +least one other Committer must agree. + +A community member may leave a Project for any reason. They must communicate +this desire to a Committer in the Project. + + +Disbanding a Project +-------------------- + +A Project may be disbanded without Platform Group interference if all +Committers assigned to the Project wish it so. + +The Platform Group may disband a project with a three-fourths majority. + +When a Project is disbanded, its mailing list must be made read-only, and its +archives must be retained. The Platform Group may destroy the Project's Web +space only under extenuating circumstances. In the event of destruction, URLs +must be set to return a '410 Gone' response. + + + +Interest Groups +=============== + +Our second act in this charter is to define "Interest Groups". An Interest +Group is a collective of contributors working to complete a single task. This +task should be clearly defined, with a reasonable expectation of completion. + +An Interest Group is more informal than a Project; it will only be assigned a +mailing list if a need for one is demonstrated. Additionally, Interest Groups +related to a package or set of packages will not have an official branch of +packages.git created. It is expected that Interest Groups will work with any +relevant Project(s) to accomplish their packaging tasks. + +Interest Groups will be granted Web space for any documentation they feel +appropriate. Interest Groups, like Projects, shall maintain a list of +affiliated Committers on this Web space. They may, additionally, list +non-Committer regular contributors, though this is not required. + + + +Platform Group +============== + +This charter, as with most of the Adélie Linux system, depends heavily on a +functional Platform Group, which acts as the "root" of the structure. As such, +a formal declaration of the Platform Group's responsibilities is provided in +this section. Additionally, addition and removal of members of the Platform +Group are discussed. + +No current member of ComArb may be a concurrent member of the Platform Group. +Similarly, a member of the Platform Group may not be a concurrent member of +ComArb. + +The Project Lead is additionally the lead of the Platform Group. + + +Responsibilities +---------------- + +The Platform Group maintains the base system packages of Adélie Linux. This +includes the origin of the Platform Group's name: the kernel and toolchain. + +The Platform Group ensures orderly and efficient processes, including those +revolving around Projects and Interest Groups. + +The Platform Group handles addition and removal of Committers. + +The Platform Group determines which CPU architectures will be supported by the +Adélie Linux distribution, and in which tier. + +The Platform Group, being the base project of Adélie Linux, may not be +dissolved under any circumstance. In the event that no members are left in the +Platform Group, all Committers must vote to elect a new Project Lead. The new +Project Lead must win via simple majority of all Committers. + + +Addition +-------- + +Nomination of a new member of the Platform Group may be made by any Committer. +The new member must be an existing Committer with no disciplinary action taken +against them in the past six months. The existing Platform Group will then +hold a vote on the candidate; a simple majority will allow the addition of the +Committer to the Platform Group. + +If the Platform Group does not approve the addition of the Committer to the +Platform Group, they may be overridden by a three-fourths majority of +Committers. + + +Removal +------- + +Expulsion of a member of the Platform Group may be initiated by either a member +of the Platform Group itself, or a member of Community Arbitration. + +A vote on whether to expel the member must be held at least 48 hours after the +expulsion announcement, to avoid emotionally charged voting. During this time, +the member may make a statement if they desire to do so. + +All members of the Platform Group vote except the member being expelled. A +three-fourths majority of members must approve the expulsion. If less than +four members of the Platform Group remain to vote, then the largest possible +supermajority is required to approve the expulsion. + +If the Platform Group does not approve the expulsion, it may be overridden by a +complete approval of the expulsion by every Committer. + + +Voting +------ + +In the event of a Platform Group vote resulting in a tie, the vote of the +current Project Lead will be carried. If the Project Lead is absent, the vote +of the senior-most member of the Platform Group that is present for voting will +be carried. + +Seniority in the Platform Group is based on the time since addition to the +Platform Group; it is not based on total time contributing to the project. -- cgit v1.2.3-60-g2f50