https://wiki.alpinelinux.org/w/api.php?action=feedcontributions&user=SpaceToast&feedformat=atomAlpine Linux - User contributions [en]2024-03-28T23:05:58ZUser contributionsMediaWiki 1.40.0https://wiki.alpinelinux.org/w/index.php?title=Governance&diff=15895Governance2019-04-19T19:41:59Z<p>SpaceToast: Initialize re-org/governance document with the old interim policy.</p>
<hr />
<div>= Alpine Re-Organization =<br />
It has been suggested to keep a publicly available document for the re-organization efforts.<br />
This document, being on a public wiki, can serve this purpose.<br />
<br />
== Old Interim Policy ==<br />
This is a direct dump of the old Interim Policy.<br />
They are pasted mostly verbatim, with some light formatting for wiki-compatibility added.<br />
<br />
=== Non-technical member status ===<br />
Hello,<br />
<br />
As is already known, the core team holds final responsibility for all<br />
decisions made on behalf of the project. This includes defining what<br />
a Developer actually is. The core team has not at this time delegated<br />
that responsibility. Therefore, this email serves to document a<br />
modification to what is meant by Developer status, as well as creating<br />
a track for non-technical contributors to earn Developer status (as a<br />
non-technical member). <br />
<br />
==== Member status ====<br />
A Member is any participant in the project who has been granted full<br />
rights to the project. These rights include:<br />
* the ability to nominate others for membership rights in the project<br />
* the ability to nominate others for expulsion from the project (as a last resort)<br />
* the ability to bring proposals up for a vote by the whole project<br />
* the ability to vote on proposals<br />
* an alpinelinux.org email account<br />
A contributor may become a Member by either a technical track in which<br />
case they become a Developer or Sysadmin, or a non-technical track in<br />
which case they are just a Member.<br />
<br />
A Maintainer is not a Member of the project unless they gain Developer<br />
status or are separately nominated under the non-technical Member<br />
procedure.<br />
<br />
==== Developer status ====<br />
Developer status remains largely unchanged, except that the rights<br />
exclusive to Developers and Sysadmins now belong to any Member. In<br />
other words, a Developer is now a Member who has full push rights and<br />
nothing else.<br />
<br />
==== Sysadmin status ====<br />
Sysadmin status remains largely unchanged, except that they are now<br />
just a Member who has special access to Alpine systems.<br />
<br />
==== Non-technical contributor track ====<br />
A non-technical contributor may be nominated for Member status by any<br />
other Member. As part of their nomination, they should highlight<br />
notable contributions made by the nominee.<br />
<br />
A nomination will have a period of a week, starting from the moment a<br />
core team member acknowledges the nomination. At this point,<br />
admission is decided using lazy consensus: if 2 or more core team<br />
members approve of the nomination and there are no objections, the<br />
nomination will be accepted. Otherwise the core team will discuss and<br />
come to a conclusion after the deadline is hit.<br />
<br />
If the nomination is accepted, then the infrastructure team will be<br />
directed to create the account, collecting an SSH key and any other<br />
pertinent data they need to process the account creation request.<br />
<br />
A non-technical Member may apply for Maintainer or Developer<br />
privileges later, but they will have to complete the full technical<br />
track before getting Developer privileges.<br />
<br />
=== Procedure for the admission and explusion of project members ===<br />
Hello,<br />
<br />
As you may already know, the core team holds final responsibility for<br />
all decisions made on behalf of the project. This includes the<br />
admission of maintainers and developers. The core team has not at<br />
this time delegated the responsibility of admission or expulsion of<br />
maintainers, developers, sysadmins and other project members. Thusly,<br />
this email serves to document established procedure for all of these<br />
things.<br />
<br />
==== Member status ====<br />
A Member is any participant in the project who has been granted full<br />
rights to the project. These rights include:<br />
<br />
* the ability to nominate others for membership rights in the project<br />
* the ability to nominate others for expulsion from the project (as a<br />
last resort)<br />
* the ability to bring proposals up for a vote by the whole project<br />
* the ability to vote on proposals<br />
* an alpinelinux.org email account<br />
<br />
A contributor may become a Member by either a technical track in which<br />
case they become a Developer or Sysadmin, or a non-technical track in<br />
which case they are just a Member.<br />
<br />
A Maintainer is not a Member of the project unless they gain Developer<br />
status or are separately nominated under the non-technical Member<br />
procedure.<br />
<br />
==== Admission of maintainers ====<br />
<br />
Before becoming a full developer, a prospective contributor must go<br />
through a probationary period, where they have "maintainer" status.<br />
<br />
A maintainer can push only to edge, and only to testing and community branches.<br />
<br />
Maintainers are nominated by *any* developer who is working with the<br />
contributor, by sending the nomination to the core team, preferably<br />
via Matrix or the alpine-team mailing list. The only requirement is<br />
that the developer nominating the contributor must have previously<br />
sponsored pushes of GIT commits from the contributor.<br />
<br />
A nomination will have a period of a week, starting from the moment a<br />
core team member acknowledges the nomination. At this point,<br />
admission is decided using lazy consensus: if 2 or more core team<br />
members approve of the nomination and there are no objections, the<br />
nomination will be accepted. Otherwise the core team will discuss and<br />
come to a conclusion after the deadline is hit.<br />
<br />
If the nomination is accepted, then the infrastructure team will be<br />
directed to create the account, collecting an SSH key and any other<br />
pertinent data they need to process the account creation request. The<br />
core team will set a timeline for when the new maintainer may apply to<br />
become a full developer as part of this process.<br />
<br />
==== Full developer privilege ====<br />
Once a new maintainer's probation period ends, they may be nominated,<br />
either by themselves or by a supporter, to become a full developer.<br />
<br />
A developer privilege nomination will have a period of a week,<br />
starting from the moment the core team acknowledges the nomination.<br />
At this point, granting full privileges will be decided using lazy<br />
consensus: if 4 or more core team members approve of the nomination<br />
and there are no objections, the nomination will be accepted.<br />
Otherwise the core team will discuss and come to a conclusion after<br />
the deadline is hit.<br />
<br />
If the nomination is accepted, the infrastructure team will be<br />
directed to grant the account in question full developer status.<br />
<br />
This also grants Member status.<br />
<br />
==== Non-technical contributor track ====<br />
A non-technical contributor may be nominated for Member status by any<br />
other Member. As part of their nomination, they should highlight<br />
notable contributions made by the nominee.<br />
<br />
A nomination will have a period of a week, starting from the moment a<br />
core team member acknowledges the nomination. At this point,<br />
admission is decided using lazy consensus: if 2 or more core team<br />
members approve of the nomination and there are no objections, the<br />
nomination will be accepted. Otherwise the core team will discuss and<br />
come to a conclusion after the deadline is hit.<br />
<br />
If the nomination is accepted, then the infrastructure team will be<br />
directed to create the account, collecting an SSH key and any other<br />
pertinent data they need to process the account creation request.<br />
<br />
A non-technical Member may apply for Maintainer or Developer<br />
privileges later, but they will have to complete the full technical<br />
track before getting Developer privileges. <br />
<br />
==== Expulsion of Members ====<br />
Any existing Member can nominate another Member for expulsion. This<br />
should only be done in the most extreme case. As this is a drastic<br />
measure, we require sending the request by email to<br />
the Alpine core team.<br />
<br />
We reserve the right to reject the nomination if we believe that it is<br />
unlikely to survive the expulsion process or is caused by animosity<br />
between two participants. In the latter case, the participants should<br />
resolve their problem according to the Code of Conduct.<br />
<br />
(This is meant as an extreme last resort, any Developer who abuses<br />
this process may find their expulsion nominations are ignored by the<br />
core team.)<br />
<br />
Once an expulsion request is received and acknowledged, the Member who<br />
requested the expulsion should have any supporters contact the core<br />
team. Supporters must have Member status and they must send their<br />
statement of support to the Alpine core team by email.<br />
<br />
Once a proposal reaches quorum, the core team will assign a core team<br />
member to handle the remaining process. If the proposal does not<br />
reach quorum, the process ends. Quorum is defined by the core team at<br />
the time of the proposal based on the number of active Members.<br />
<br />
At this point, the person handling the expulsion process will contact<br />
the nominee and explain the situation. The person is required to<br />
disclose the names and reasons of the people involved with the<br />
proposal. They then have two weeks to respond with a statement of<br />
their own, and are encouraged to gather their own statements of<br />
support and forward those to the core team as well. Statements of<br />
support must be originated from Members.<br />
<br />
Once the two weeks is up, the nominee may decide if they wish for the<br />
matter to be handled publicly, privately or to resign. If the nominee<br />
wishes to handle it publicly, they can write to alpine-devel about the<br />
accusations. Otherwise the person handling the expulsion process will<br />
mention it privately to all Developers.<br />
<br />
At this point, the person handling the expulsion process will call for<br />
a project-wide vote about the expulsion. If the expulsion has greater<br />
than 2/3rds majority, the nominee will be expelled. At that point,<br />
the core team will set a period of time for the expulsion, after which<br />
the nominee may re-apply to become a maintainer or be nominated for<br />
membership. If the vote fails, then the matter is dropped.</div>SpaceToast