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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to