[FFmpeg-devel] [IMP] Decisions...

[Paul B Mahol]

I hereby here declare against this "Decisions" and will act against them.

On 11/19/19, Jean-Baptiste Kempf <jb at videolan.org> wrote:
> Hello fellow developers,
>
> Last week, a large number of us met during VDD
> (https://www.videolan.org/videolan/events/vdd19/), as I had announced
> previously on this very mailing list.
>
> The meeting was long but productive, as we talked about the organization of
> our community.
> Quite a few people were present, physically, a bit more than a dozen joined
> on the IRC channel, and 8 or 9 participated in the hangouts session. And we
> took a few decisions, that I will detail here.
>
> This mail is a bit long, but please read everything before reacting.
>
> But first, the people present were:
> - Thilo
> - Kyle
> - Ronald
> - Vittorio
> - Josh
> - Rodger (nonvoting)
> - Kieran
> - James Darnley
> - Sergio (nonvoting)
> - Steven Liu
> - Jan Ekström
> - Nikki (nonvoting)
> - Thierry Foucu
> - Carl Eugen
> - Lynne
> - Janne
> - Martin
> - Diego (nonvoting)
> - Anton (nonvoting)
> - Luca (nonvoting)
> - Jessica (nonvoting)
> - Michael Bradshaw
> - Lydia (nonvoting)
> - jb (nonvoting)
>
> On the hangouts and IRC, 3 people voted remotely, through jb, as a prox:
> - Michael
> - Jamrial
> - Kurosu
>
> ------
>
> We voted about a few things to organize the community.
>
> First, we decided that we needed to act, and bootstrap some actions that
> will lead to more structured organization in the future.
> Of course, nothing is immutable, but we needed to start somewhere.
>
> Note that all the decisions taken will be validated in 2 months, during the
> FOSDEM meeting. See the appendix of this email.
>
> 1) The first main decision was to define who would be allowed to vote on the
> future votes.
> Aka "Who are the electors?"
>
> Several options were presented, including: random(), old committee, active
> developers (as defined as more than 20 non-trivial commits in the last 36
> months) and a few fixed people helping - like roots, jb + lydia.
>
> The votes were almost unanimous for the "active developers", as defined
> currently as:
> - developers who have more than 20 non-trivial (changing the output of the
> compiler) committed patches in the last 36 months and a handful of fixed
> non-developer people (like roots)
> One vote was for the old committee, for information.
>
> Note that some people who voted for this method are de facto excluded from
> voting because of this very method :)
>
> Those people are collectively defined as the Developer General Assembly, aka
> GA, the electors.
> The GA will vote in referendums that are impacting the whole project
> ("Should the license be LGPLv4?", "Should the codebase be moved to Go?",
> "Should the bike shed be blue?") and will vote for their representatives in
> the committees.
>
> 2) What voting mechanism should we use?
>
> This discussion was complex, and mentioned FPTP, ranked-voting, approval
> voting, 2-turns, random.
> Rodger seemed to master the subject more than we did and a few other people
> shared opinions and
>
> We voted on the method of voting and decided, in a very very large majority
> to use a ranked-voting system, similar to what other free software projects
> are using.
> If people care strongly about which type of ranked-voting we should use,
> please contact Rodger and find a consensus, so we can use that in the
> future.
>
> 3) Technical Resolution Committee
>
> We then elected, with the new method, the members for the Technical
> Resolution Committee, made of 5 people. (TC)
>
> This committee is here to arbitrate conflicts on technical matters ("Should
> we use 2 parameters to this function?" "Should this be a filter or a
> demuxer?", "Should this structure be split?")  when discussion happens on
> the mailing list and there is no simple answer, and the whole thread start
> to derive into nastiness.
>
> This committee is not here to decide on directions or vision, or decide on
> generic topics, since this is the mandate of the GA.
> However, the decisions from this committees are binding, therefore, you must
> apply the committee decision.
> Reopening discussions later are always possible, at a GA meeting.
>
> The conflict resolution process will be discussed later, and a proper
> document will be defined, but I fear this is outside of the scope of the
> current mail.
>
> The vote was very long to count, because of ranked choice done manually
> (thanks Rodger!), but with little surprise, the people elected were:
> - Michael
> - James Almer
> - Ronald
> - Martin
> - Anton
>
> In the future, we will have an extra step of asking the people elected to
> agree to their charges.
> This being a bootstrap, with a very limited amount of time available, and
> with newer elections in less than 3 months, we skipped that part, for this
> first vote.
>
> 4) Community Conflict committee
>
> We finally elected, with the new method, the members of the Community
> Committee, made of 5 people. (CC)
>
> This committee is here to arbitrate personal conflicts between members of
> the community, and take actions (read:  "kick butts") if people do not
> behave nicely. You do not have to like everyone, but you can act like
> grown-ups.
> Again, CC resolutions are binding, but GA has full control and override of
> the CC.
>
> The process and rules about the community will be debated further, at a
> later time, for the same reason as TC.
>
> The vote was even longer, than the  previous one, and we were all tired, but
> the elected people where:
> - JB (/me)
> - Lydia
> - James Almer
> - Thilo
> - Carl Eugen
>
> 5) Developer meetings
>
> We also agreed, yet did not vote, that we should organize regular developer
> meetings, online to debate and open new votes.
> The suggested regularity is every month.
>
>
> ------
>
>
> As you can see, nothing specific was agreed on (we did not vote to move to
> C++17 :D), but we defined the process to get things done in the future, and
> how to get there in a peaceful way.
>
> Because I said on my previous email that we will not take decisions during
> the meeting, as Carl remarked a few times during the meeting, nothing said
> above will be binding before 2 weeks.
> That means that in 2 weeks, when we do the next FFmpeg developer meeting
> (Dec 1st, 2nd, 3rd?) we activate all that was said before, unless very
> strong opposition.
>
> If you have strong objections to what was decided above, you have 2 weeks to
> speak up.
> But to go back from what was decided, we will need an opposition from more
> than a few active developers, in order to overturn the number of active
> people who were present.
> I would advise also, to think a bit before answering to this email.
>
>
> Then, as you probably saw the obvious flaw, the people elected and the
> election mode were not voted by the GA.
> But we had to bootstrap from somewhere. (stage 1)
>
> Therefore a main GA will happen during FOSDEM and then we will revote on:
> - who are the electors (I expect fine tuning of number of commits and
> counting period)
> - new TC election,
> - new CC election.
>
> This will make it that those TC and CC are only elected for 2 months.
>
> The way of working of the TC, CC are yet to be fully defined. I will do that
> in the next 2 weeks. I'd love constructive ideas and feedback on that part.
> The way of voting during the GA is yet to be fully defined. Rodger will work
> on that, and he will love constructive feedback.
>
> I'm available to discuss over IRC, IRL, Hangouts/Skype/Telegram, email or
> whatever mean of communication that you prefer, if something is not clear or
> you have positive ideas on how to improve.
>
> Hoping for the best for the future,
>
> Freely,
>
> --
> Jean-Baptiste Kempf -  President of VideoLAN
> +33 672 704 734
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".