Innsill: +category:Development

2019-09-14T08:35:33Z

← Older revision		Revision as of 08:35, 14 September 2019
Line 1:		Line 1:
			{{TOC right}}

	= Alpine Re-Organization =		= Alpine Re-Organization =
	It has been suggested to keep a publicly available document for the re-organization efforts.		It has been suggested to keep a publicly available document for the re-organization efforts.
Line 202:		Line 204:
	the nominee may re-apply to become a maintainer or be nominated for		the nominee may re-apply to become a maintainer or be nominated for
	membership. If the vote fails, then the matter is dropped.		membership. If the vote fails, then the matter is dropped.


			[[category:Development]]

SpaceToast: Initialize re-org/governance document with the old interim policy.

2019-04-19T19:41:59Z

Initialize re-org/governance document with the old interim policy.

New page

= Alpine Re-Organization =
It has been suggested to keep a publicly available document for the re-organization efforts.
This document, being on a public wiki, can serve this purpose.

== Old Interim Policy ==
This is a direct dump of the old Interim Policy.
They are pasted mostly verbatim, with some light formatting for wiki-compatibility added.

=== Non-technical member status ===
Hello,

As is already known, the core team holds final responsibility for all
decisions made on behalf of the project. This includes defining what
a Developer actually is. The core team has not at this time delegated
that responsibility. Therefore, this email serves to document a
modification to what is meant by Developer status, as well as creating
a track for non-technical contributors to earn Developer status (as a
non-technical member).

==== Member status ====
A Member is any participant in the project who has been granted full
rights to the project. These rights include:
* the ability to nominate others for membership rights in the project
* the ability to nominate others for expulsion from the project (as a last resort)
* the ability to bring proposals up for a vote by the whole project
* the ability to vote on proposals
* an alpinelinux.org email account
A contributor may become a Member by either a technical track in which
case they become a Developer or Sysadmin, or a non-technical track in
which case they are just a Member.

A Maintainer is not a Member of the project unless they gain Developer
status or are separately nominated under the non-technical Member
procedure.

==== Developer status ====
Developer status remains largely unchanged, except that the rights
exclusive to Developers and Sysadmins now belong to any Member. In
other words, a Developer is now a Member who has full push rights and
nothing else.

==== Sysadmin status ====
Sysadmin status remains largely unchanged, except that they are now
just a Member who has special access to Alpine systems.

==== Non-technical contributor track ====
A non-technical contributor may be nominated for Member status by any
other Member. As part of their nomination, they should highlight
notable contributions made by the nominee.

A nomination will have a period of a week, starting from the moment a
core team member acknowledges the nomination. At this point,
admission is decided using lazy consensus: if 2 or more core team
members approve of the nomination and there are no objections, the
nomination will be accepted. Otherwise the core team will discuss and
come to a conclusion after the deadline is hit.

If the nomination is accepted, then the infrastructure team will be
directed to create the account, collecting an SSH key and any other
pertinent data they need to process the account creation request.

A non-technical Member may apply for Maintainer or Developer
privileges later, but they will have to complete the full technical
track before getting Developer privileges.

=== Procedure for the admission and explusion of project members ===
Hello,

As you may already know, the core team holds final responsibility for
all decisions made on behalf of the project. This includes the
admission of maintainers and developers. The core team has not at
this time delegated the responsibility of admission or expulsion of
maintainers, developers, sysadmins and other project members. Thusly,
this email serves to document established procedure for all of these
things.

==== Member status ====
A Member is any participant in the project who has been granted full
rights to the project. These rights include:

* the ability to nominate others for membership rights in the project
* the ability to nominate others for expulsion from the project (as a
last resort)
* the ability to bring proposals up for a vote by the whole project
* the ability to vote on proposals
* an alpinelinux.org email account

A contributor may become a Member by either a technical track in which
case they become a Developer or Sysadmin, or a non-technical track in
which case they are just a Member.

A Maintainer is not a Member of the project unless they gain Developer
status or are separately nominated under the non-technical Member
procedure.

==== Admission of maintainers ====

Before becoming a full developer, a prospective contributor must go
through a probationary period, where they have "maintainer" status.

A maintainer can push only to edge, and only to testing and community branches.

Maintainers are nominated by *any* developer who is working with the
contributor, by sending the nomination to the core team, preferably
via Matrix or the alpine-team mailing list. The only requirement is
that the developer nominating the contributor must have previously
sponsored pushes of GIT commits from the contributor.

A nomination will have a period of a week, starting from the moment a
core team member acknowledges the nomination. At this point,
admission is decided using lazy consensus: if 2 or more core team
members approve of the nomination and there are no objections, the
nomination will be accepted. Otherwise the core team will discuss and
come to a conclusion after the deadline is hit.

If the nomination is accepted, then the infrastructure team will be
directed to create the account, collecting an SSH key and any other
pertinent data they need to process the account creation request. The
core team will set a timeline for when the new maintainer may apply to
become a full developer as part of this process.

==== Full developer privilege ====
Once a new maintainer's probation period ends, they may be nominated,
either by themselves or by a supporter, to become a full developer.

A developer privilege nomination will have a period of a week,
starting from the moment the core team acknowledges the nomination.
At this point, granting full privileges will be decided using lazy
consensus: if 4 or more core team members approve of the nomination
and there are no objections, the nomination will be accepted.
Otherwise the core team will discuss and come to a conclusion after
the deadline is hit.

If the nomination is accepted, the infrastructure team will be
directed to grant the account in question full developer status.

This also grants Member status.

==== Non-technical contributor track ====
A non-technical contributor may be nominated for Member status by any
other Member. As part of their nomination, they should highlight
notable contributions made by the nominee.

A nomination will have a period of a week, starting from the moment a
core team member acknowledges the nomination. At this point,
admission is decided using lazy consensus: if 2 or more core team
members approve of the nomination and there are no objections, the
nomination will be accepted. Otherwise the core team will discuss and
come to a conclusion after the deadline is hit.

If the nomination is accepted, then the infrastructure team will be
directed to create the account, collecting an SSH key and any other
pertinent data they need to process the account creation request.

A non-technical Member may apply for Maintainer or Developer
privileges later, but they will have to complete the full technical
track before getting Developer privileges.

==== Expulsion of Members ====
Any existing Member can nominate another Member for expulsion. This
should only be done in the most extreme case. As this is a drastic
measure, we require sending the request by email to
the Alpine core team.

We reserve the right to reject the nomination if we believe that it is
unlikely to survive the expulsion process or is caused by animosity
between two participants. In the latter case, the participants should
resolve their problem according to the Code of Conduct.

(This is meant as an extreme last resort, any Developer who abuses
this process may find their expulsion nominations are ignored by the
core team.)

Once an expulsion request is received and acknowledged, the Member who
requested the expulsion should have any supporters contact the core
team. Supporters must have Member status and they must send their
statement of support to the Alpine core team by email.

Once a proposal reaches quorum, the core team will assign a core team
member to handle the remaining process. If the proposal does not
reach quorum, the process ends. Quorum is defined by the core team at
the time of the proposal based on the number of active Members.

At this point, the person handling the expulsion process will contact
the nominee and explain the situation. The person is required to
disclose the names and reasons of the people involved with the
proposal. They then have two weeks to respond with a statement of
their own, and are encouraged to gather their own statements of
support and forward those to the core team as well. Statements of
support must be originated from Members.

Once the two weeks is up, the nominee may decide if they wish for the
matter to be handled publicly, privately or to resign. If the nominee
wishes to handle it publicly, they can write to alpine-devel about the
accusations. Otherwise the person handling the expulsion process will
mention it privately to all Developers.

At this point, the person handling the expulsion process will call for
a project-wide vote about the expulsion. If the expulsion has greater
than 2/3rds majority, the nominee will be expelled. At that point,
the core team will set a period of time for the expulsion, after which
the nominee may re-apply to become a maintainer or be nominated for
membership. If the vote fails, then the matter is dropped.

Governance - Revision history

Innsill: +category:Development

SpaceToast: Initialize re-org/governance document with the old interim policy.