[dbsrgits/DBIx-Class.git] / GOVERNANCE

DBIx::Class Core Team and Voting System

Non normative section:

DBIx::Class originally operated under a BDFL system, but one where it was
expected that an informal core team would be maintained, and that where
consensus could not be pre-assumed, the core team and/or the user base
would be consulted publically such that measured decisions could be made.

This document is intended to formalise a form of this system, while still
providing room for the system to adapt later as required.

It is intended that this system provides confidence to the user base that
decisions will be made in the open and that their wishes will be taken into
account.

It is also intended that this system allows business as usual to happen
without unnecessary red tape.

It is not intended that this system becomes the primary decision making
process in and of itself; instead, it is intended that this system is used
to ratify consensus as formed by discussion, and only sparingly as a tie
breaking system when consensus cannot be reached.

Normative section:

Terms: VM - Voting Member - part of the benevolent dictatorship
       LS - List Subscriber - a subscriber to the mailing list
       LAV - List Aggregate Vote - the aggregate vote of the non-VM LSes

Voting Members are:

  Matt S Trout (mst) cpan:MSTROUT
  Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
  Frew Schmidt (frew) cpan:FREW
  Jess Robinson (castaway) cpan:JROBINSON

PAUSE release perms are to be held by:

  Matt S Trout (mst) cpan:MSTROUT
  Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
  Frew Schmidt (frew) cpan:FREW
  Jess Robinson (castaway) cpan:JROBINSON

First come permissions are to be held by FREW.

(the above two lists may or may not be identical at any given time)

A resolution must be proposed and then successfully voted upon to:

  - Make a PAUSE-indexed (i.e. non-dev) release of DBIx::Class
  - Make changes to the master and blead branches of the repository
  - Amend this document

This document is currently in bootstrap phase, and as such no merges will be
made to master or blead until this sentence is removed.

A resolution that amends the 'PAUSE release perms' list is to be assumed to
also intend the permission within PAUSE itself to be updated accordingly.

Adding or removing entries from the list of situations requiring resolutions
is absolutely a valid topic for resolutions.

A resolution may be proposed for reasons including, but not limited to:

  - Force/revert/block a branch merge
  - Add/remove a commit bit
  - Resolve a design discussion
  - Anything you like, under the assumption frivolous proposals will be
    voted down naturally anyway

Merges to topic branches and similar actions that do not have a resolution
attached may be made at the discretion of those with ability to do so, but
a developer unsure if the merge will be uncontroversial is expected to ping
the list first so a vote can be called if people believe it to be required.

Rules that restrict this "ask unless you're sure" trust-by-default position
are also absolutely a valid topic for resolutions.

Resolution proposal:

A resolution is proposed by starting a new thread entitled 'PROPOSAL: ...'

A resolution must be seconded before it is voted upon.

If a VM makes or seconds a proposal, they are required to abstain from
voting upon it.

If a non-VM LS makes or seconds a proposal, no such restriction applies.

Resolution voting:

Once a proposal is seconded, the initial proposer may start a new thread
entitled 'VOTE: ...' (voting does not automatically begin after seconding
in case other feedback leads the proposer to wish to alter and re-present
their proposal).

Each VM may cast one vote, either +1, -1 or abstain.

Each non-VM LS may post +1 or -1, and the aggregate of those form the LAV.

Voting closes after 72h from when the proposal was first posted.

A resolution passes if the VM total is at least +1 and the LAV is
non-negative, to avoid requiring the list members to expend time to vote on
business as usual while still providing them a veto.

Resolution forcing:

If a resolution gains a positive LAV, but is voted down by the VMs, a force
vote may be proposed. This requires two list members who did not propose or
second the initial resolution to propose and second the force vote.

A force vote also lasts 72h, and is LAV-only. If it receives at least 25%
more +1s than -1s, the resolution passes no matter the VM vote.

This mechanism is not intended to be needed on a regular basis, but exists
to permit the list to forcibly recall a VM if they believe it to be necessary.

Once a resolution has passed, the resolution will be carried out by those with
the power to do so.  It will not be reverted without a new resolution
amending or reversing the decision of the previous once.

Passed resolutions will be recorded in a RESOLUTIONS file maintained next
to this document.
Commit	Line	Data
d8cf3aa3	1	DBIx::Class Core Team and Voting System
	2
	3	Non normative section:
	4
	5	DBIx::Class originally operated under a BDFL system, but one where it was
	6	expected that an informal core team would be maintained, and that where
	7	consensus could not be pre-assumed, the core team and/or the user base
	8	would be consulted publically such that measured decisions could be made.
	9
	10	This document is intended to formalise a form of this system, while still
	11	providing room for the system to adapt later as required.
	12
	13	It is intended that this system provides confidence to the user base that
	14	decisions will be made in the open and that their wishes will be taken into
	15	account.
	16
	17	It is also intended that this system allows business as usual to happen
	18	without unnecessary red tape.
	19
	20	It is not intended that this system becomes the primary decision making
	21	process in and of itself; instead, it is intended that this system is used
	22	to ratify consensus as formed by discussion, and only sparingly as a tie
	23	breaking system when consensus cannot be reached.
	24
	25	Normative section:
	26
	27	Terms: VM - Voting Member - part of the benevolent dictatorship
	28	LS - List Subscriber - a subscriber to the mailing list
	29	LAV - List Aggregate Vote - the aggregate vote of the non-VM LSes
	30
	31	Voting Members are:
	32
	33	Matt S Trout (mst) cpan:MSTROUT
	34	Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
	35	Frew Schmidt (frew) cpan:FREW
	36	Jess Robinson (castaway) cpan:JROBINSON
	37
	38	PAUSE release perms are to be held by:
	39
	40	Matt S Trout (mst) cpan:MSTROUT
	41	Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
	42	Frew Schmidt (frew) cpan:FREW
	43	Jess Robinson (castaway) cpan:JROBINSON
	44
	45	First come permissions are to be held by FREW.
	46
	47	(the above two lists may or may not be identical at any given time)
	48
	49	A resolution must be proposed and then successfully voted upon to:
	50
	51	- Make a PAUSE-indexed (i.e. non-dev) release of DBIx::Class
	52	- Make changes to the master and blead branches of the repository
	53	- Amend this document
	54
	55	This document is currently in bootstrap phase, and as such no merges will be
	56	made to master or blead until this sentence is removed.
	57
	58	A resolution that amends the 'PAUSE release perms' list is to be assumed to
	59	also intend the permission within PAUSE itself to be updated accordingly.
	60
	61	Adding or removing entries from the list of situations requiring resolutions
	62	is absolutely a valid topic for resolutions.
	63
	64	A resolution may be proposed for reasons including, but not limited to:
65
66	- Force/revert/block a branch merge
67	- Add/remove a commit bit
68	- Resolve a design discussion
69	- Anything you like, under the assumption frivolous proposals will be
70	voted down naturally anyway
71
72	Merges to topic branches and similar actions that do not have a resolution
73	attached may be made at the discretion of those with ability to do so, but
74	a developer unsure if the merge will be uncontroversial is expected to ping
75	the list first so a vote can be called if people believe it to be required.
76
77	Rules that restrict this "ask unless you're sure" trust-by-default position
78	are also absolutely a valid topic for resolutions.
79
80	Resolution proposal:
81
82	A resolution is proposed by starting a new thread entitled 'PROPOSAL: ...'
83
84	A resolution must be seconded before it is voted upon.
85
86	If a VM makes or seconds a proposal, they are required to abstain from
87	voting upon it.
88
89	If a non-VM LS makes or seconds a proposal, no such restriction applies.
90
91	Resolution voting:
92
93	Once a proposal is seconded, the initial proposer may start a new thread
94	entitled 'VOTE: ...' (voting does not automatically begin after seconding
95	in case other feedback leads the proposer to wish to alter and re-present
96	their proposal).
97
98	Each VM may cast one vote, either +1, -1 or abstain.
99
100	Each non-VM LS may post +1 or -1, and the aggregate of those form the LAV.
101
102	Voting closes after 72h from when the proposal was first posted.
103
104	A resolution passes if the VM total is at least +1 and the LAV is
105	non-negative, to avoid requiring the list members to expend time to vote on
106	business as usual while still providing them a veto.
107
108	Resolution forcing:
109
110	If a resolution gains a positive LAV, but is voted down by the VMs, a force
111	vote may be proposed. This requires two list members who did not propose or
112	second the initial resolution to propose and second the force vote.
113
114	A force vote also lasts 72h, and is LAV-only. If it receives at least 25%
115	more +1s than -1s, the resolution passes no matter the VM vote.
116
117	This mechanism is not intended to be needed on a regular basis, but exists
118	to permit the list to forcibly recall a VM if they believe it to be necessary.
119
120	Once a resolution has passed, the resolution will be carried out by those with
121	the power to do so. It will not be reverted without a new resolution
122	amending or reversing the decision of the previous once.
123
124	Passed resolutions will be recorded in a RESOLUTIONS file maintained next
125	to this document.