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

[Jean-Baptiste Kempf]

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