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
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.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel