[FFmpeg-devel] Voting committee

[Nicolas George]

L'octidi 28 fructidor, an CCXXIII, Nicolas George a écrit :
> I have been thinking of a practical proposal myself, I will word it and post
> it shortly.

Here it is. Please comment.

> I strongly think that we will able to reach unanimous consensus about the
> members of the second stage list, and clear consensus about the decision
> rules. If that happens, there is no doubt this is legitimate.

Better comparison: bootstraping a compiler rather than an OS. Unanimous
consensus on the list of current developers is like reaching the fixed point
where the compiler can compile itself into the exact same binary.

I really think we can achieve it. We just need to keep minor personal
dislikes for ourselves. Maybe I think that Someone is a complete idiot, but
if the other developers that I trust and respect do not think so, I should
shut up for the sake of unity; after all, it's just one person, it will not
derail the project.

Regards,

-- 
  Nicolas George
-------------- next part --------------
Important decisions about FFmpeg are made following a due process ensuring
fairness and legitimacy. These decisions are hereafter called Decisions with
a capital.

Principles and college of Decision makers
=========================================

The Decisions are made by the current Active FFmpeg Developers, preferably
unanimously after discussion, or at least with a clear majority, but if all
that fails with a simple majority. The Decisions and decision process are
public, on the mailing list.

[ NdCigaes: I do not think that we need special cases, like 2/3 majority. ]

The list of current FFmpeg Developers is maintained on the website under
version control; it is not always updated for active/inactive status.

The initial list of FFmpeg developers has been decided by unanimous
consensus on the public mailing list.

[ NdC: I expect some people will think "$person is a fraud, he/she should
not be in the list", but I hope that they will realize that having them on
the list is not a severe problem and, for the good of the project ambiance,
keep their opinion for themselves. ]

The present decision process was approved the same way and can be updated by
later Decisions. It is kept under revision control too.

New FFmpeg developers can be added to the list by a Decision of the current
developers, ideally by unanimous consensus.

[ NdC: if someone thinks "$person is a fraud", it is better they keep it to
themselves, but if a lot of persons think so, then maybe $person should not
be considered a FFmpeg developer. For that reason, the best course of action
is probably to discuss the addition in private first, and propose it
publicly only when it has become obvious that the Decision will pass and
those against will shut up. I do not know if it must be made a rule or not. ]

A Decision can also remove a member from the list, but we hope it will never
need to happen.

A FFmpeg Developer is considered Active if he or she has at least 10
commits, 20 messages on the devel mailing list or 40 answers on the users
mailing lists, or any linear combination of this, in the last 365 days, and
inactive otherwise. If a developer rises above the activity threshold after
less than 365 days inactivity, he or she is automatically reinstated; after
that delay, he or she is by right removed from the list, but can of course
ask to be reinstated through a Decision like anybody else. The
Active/inactive status is considered at the exact time where the call for a
Decision is posted on the mailing list.

[ NdC: this criterion can easily be gamed, but I do not think it matters.
Also, I do not know how to count IRC or Trac; are there people who are only
active there and should be considered Active Developers? ]

Decision process
================

Decisions are made by calling for a consultation on the devel mailing list.
Calls for a Decision must include the "[DECISION]" tag in their subject.
People answering to the call on the mailing list should try to remember to
remove the tag. A mail thread, as defined by the References and In-Reply-To
headers, can contain only one call for Decision at most. If a new related
one must be posted, it needs to be in a new thread.

[ NdC: rationale: avoid developers missing calls amongst an unrelated
subthread with the tag. ]

Calls for decisions should include a deadline, by default and at least 7
days starting from the arrival of the call on the mailing list archive. The
deadline can be selected longer if circumstances suggest it (holidays,
important developer known to be temporarily unreachable, etc.).

Calls for Decisions can be either by clear consensus or formal vote.

The person calling for a Decision is responsible for summarising the
outcome.

Several calls for Decisions can be bundled together if they are related. The
call must be worded very clearly, and the replies as well.

Clear consensus
---------------

Clear consensus can happen when the issue has already been discussed and a
choice seems to be accepted by most people. The call must include the exact
wording for the motion, a list of the known strong proponent of the motion,
a summary of their arguments, a list of the known strong opponents of the
motion (if any) and a summary of their arguments (people redacting the call
should check the summary with them).

Support or opposition to the Decision must be posted as a direct reply to
the call, according to the mailing list netiquette. The reply must include,
in its first sentence, an unambiguous statement of the nature of the reply
and a terse rationale for it.

The Active Developers can, by their reply, add or remove themselves from the
lists of strong proponents or opponents, or oppose to the decision process
itself. Later replies by the same Developers supersedes earlier ones.

An objection to the decision process itself suspends the discussion until it
has been either resolved either by a Decision or withdrawn by its author.
The deadline is updated accordingly.

[ NdC: if someone uses this clause to filibuster the Decision, the other
Developers can Decide to kick them out. ]

People who do not have a strong opinion on the Decision should abstain from
expressing it formally, but informal discussion can continue until the
deadline.

When the deadline arrives, the Decision is adopted if the ratio of strong
proponents versus strong opponents is at lease 3/2. Otherwise, the Decision
may be called again as a formal vote.

Formal vote
-----------

If it is deemed necessary, a Decision can be made by formal vote. The call
must include a list of proposed outcomes.

Developers vote for their preferred outcome by replying directly to the call
on the public mailing list. The same rules about the replies, objections to
the process, etc., as for the clear consensus case apply.

The ballots must be worded the following the same rules as the ballots for
Debian general resolutions, and the outcome is decided using the same
algorithm.

[ NdC: probably better to copy-paste the rules here. ]

[ NdC2: I do not think we require a formal way to decide what motions are
proposed on the ballot. ]

Leading Committee and Minor Decisions
=====================================

The Active FFmpeg Developers can Decide to nominate a Leader or Leading
Committee. The Leading Committee can make Minor Decisions to alter the
policy of the project, but it can not make a Minor Decision overriding a
real Decision.

The Leading Committee should intervene whenever an Active FFmpeg Developer
ask them to.

The Leading Committee is Decided for a calendar year, from date to date. It
can be extended with a clear consensus Decision. Anyone can call for a
Decision to change the Leading Committee before that.

[ NdC: so basically, the Leader must ask, once per year "are you happy with
me one more year?", but if a majority is unhappy with them, they can kick
them out before that. ]

Usage guidelines
================

This process is formalized in order to have a safety net with perfect
legitimacy in case strong disagreements arise.

In everyday handling of the project, clear consensus Decisions can be used
to put to rest controverted discussions that resolve to a matter of taste
and to welcome new members.

Developers should try to avoid the need for more formal decision making.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150914/709dfebe/attachment.sig>