I hereby here declare against this "Decisions" and will act against them.
On 11/19/19, Jean-Baptiste Kempf <j...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ 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".
