[FFmpeg-devel] Democratization

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Vittorio Giovara
> Sent: Friday, January 31, 2025 1:14 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Democratization
> 
> On Fri, Jan 31, 2025 at 12:22 AM Soft Works <
> softworkz-at-hotmail.com at ffmpeg.org> wrote:
> 
> > > That does not mean it would be worth trying something different.
> I
> > > already
> > > listed the incidents I've just seen happen before my eyes in this
> > > mailing
> > > list and these are not fun incidents. Ideally there should be
> some
> > > guarantee beyond Micheal's word not to repeat them again. What
> you're
> > > saying is "this is how it has always been, therefore we should
> just
> > > accept
> > > it", which is unfair, especially to the most active contributors.
> >
> > I'm not saying you should accept it because "this is how it has
> always
> > been".
> > I'm saying you should accept it because the project has a private
> > ownership which "is how it has always been".
> > This has been clear ever since and for all contributors. The
> project
> > doesn't own the code - you are free to fork at any time and run
> your own
> > thing. But there's nothing from which you could derive any right to
> demand
> > for a change of ownership, neither is there any basis on which you
> could
> > demand any "guarantees" regarding the owner's actions.
> >
> 
> I think you are missing the point that there is no scenario in which
> the
> drama/protest/bullying/you-name-it will stop, if the current
> situation doesn't change. 

I see this and I do agree to that, we just disagree about the way to solved it.

> Either Micheal needs to step up as leader of the
> project
> and stop the pretense of democracy, or he lets the community use the
> governance that he himself established. This half assed system is
> unsurvivable, and the only thing that is being requested is
> establishing a
> process, not transferring control 

Not transferring control? You said you want guarantees "beyond Michael's word" that certain things can no longer happen. How could that work without transferring control?`


> I don't understand how you don't see that the community is divided
> *exactly* because there is no clear control.


> And I'm sorry that your opinion is going in the opposite direction,
> but I
> personally don't think there should be a system that favors some
> people and not others 

I agree to that, I just don't believe that community voting on everything can help with that.
As laid out in other messages before, I'd prefer the installment of a number of "positions" for which people can volunteer and get elected for a certain period. But those positions would not only be about making decisions but also include duties for bringing the project forward and making sure that contributions get reviewed.


> No? The type of emails I am sending are bothering you, 

They are no bothering me but I think they are causing damage to the project and should stop.

> that's why you spend 4 times as many words to reply to me.

No, that's just a habit and has nothing to do with you.



> > > > Finally, there are also contributors who don't care about
> > > community,
> > > > membership or influence - they just want to get their code
> merged
> > > without
> > > > trouble. Will they vote for a community governance where every
> > > little nit
> > > > from someone will require to conduct a vote on it?
> > > >
> > >
> > > Another "what if" of an unlikely scenario
> >
> > Unlikely? That applies to all those contributors who I met in the
> past
> > years, tried to make a contribution and walked away with the
> conclusion
> > that it's pointless and not worth trying ever again in the future!
> >
> > > in the unlikely case of conflict we have a TC that does what you
> > describe when needed.
> > > I'm sure you understand 5 people have an easier time managing a
> case
> > than the whole community.
> >
> > This it totally ineffective. The current reality (especially for
> > non-established contributors) is often something like this:
> >
> >
> > - You make a submission
> >   - Either nobody ever reacts
> >   - Or:
> >     - ffMember1 says "no" to A and B
> >     - ffMember2 says "no" to C
> > - Of course nobody told you what to do instead, so you need
> >   to "guess" what they want and make an updated submission with
> >   changes A1, B1 and C1
> >   - Then
> >     - ffMember1 says "no" to B1 (nothing against A1)
> >     - ffMember2 says "no" to C1 and now also D
> >     - ffMember3 says "no" to A1 and E
> > - Next guessing to address issues with A2, B2, C2, D1 and E1
> >   - Then
> >     - ffMember1 says nothing
> >     - ffMember2 says nothing
> >     - ffMember3 says "no" E1 and now also G
> > - Next guessing to address issues: E2 and G1
> >   - Then
> >     - ffMember1 says nothing
> >     - ffMember2 says nothing
> >     - ffMember3 says nothing
> > - You bump, you ping - no response
> > - You bump and ping
> >     - ffMember1 says "I have told you that B1 is "no" and A1 is
> "no"
> >       (has never reviewed A2 and B2)
> >     - ffMember3 says "like ffMember1 said, as long you don't fix
> A1,
> >       it can't be merged"
> >       (even though he had asked for A2 and seemingly accepted A2 by
> not
> >       mentioning it on the next review)
> > - Now you stand there without even having a clue what to do to
> satisfy
> >   everyone. If you are keen, you might ask again what to do
> instead, but
> >   while you can get lots of responses for the "no"s, you rarely get
> >   responses on the "how then?" questions, probably because
> ffMemberX
> >   is too afraid of seeing an ffMemberY contradicting.
> >
> > And then the contributor should contact the TC?
> >
> > - First of all, most don't even know about its existence
> > - If one knows about its existence, one might still not know how to
> > contact it
> > - And finally, you don't even know exactly which question/request
> to make
> > to the TC
> >   - It's not like you want X and somebody else wants Y
> >   - It's rather like some said no to A, A1, nobody said something
> to A2
> > and you would happily do A3 or A4 or A5 or A6 - because you don't
> care but
> > you are tired of guessing
> >
> >
> > What an external contributor wants instead is this:
> >
> > - You make a submission
> >   - Maintainer says
> >     - A needs to be done like A1
> >     - B needs to be done like B1
> >   - PersonInCharge  says
> >     - C needs to be done like C1
> >     - D needs to be done like D1
> > - You make changes A1, B1, C1, D1
> >   - Maintainer LGTM
> >   - PersonInCharge says C1 should better be like C2
> > - You make changes C2
> >   - PersonInCharge says LGTM
> > - Merged + Done
> >
> >
> > Hardly any external contributor is interested in any committees or
> having
> > the community voting about their contributions. They just want to
> get
> > attention and be told what to do to get their code into a form that
> it will
> > get merged - as simple as that.
> >
> 
> So you're disagreeing with Micheal that every contributor should get
> a vote.
> Good, something we agree on :)

I have no strong opinions on this subject, except the realization that it will never be 100% fair and some will always feel disadvantaged.


> > Before calling for a vote, they will rather give up and walk away.
> But in
> > case they already made a few contributions and are entitled to
> vote, they
> > will surely not vote for something which makes their contribution
> process
> > even more complicated, lengthy and unpredictable.
> >
> 
> In general dismissing something because it's complicated is not a
> good view of any developer.

It's not about being complicated, it's about the time it takes and every developer needs to manage the time spent on something. If the development of a patch takes 1h, but getting it merged into ffmpeg takes 8h, spread over several weeks, many will just skip submission. 

There's a HUGE TREASURE of fixes and feature implementations for ffmpeg spread all over the net, which just haven't been submitted by their developers (or submitted once but ignored because the author didn't spend time to ping and remind).


> > Besides that, it's already clear that this won't happen, even when
> a
> > majority would want it, so it's probably more productive to accept
> that and
> > rather participate in the suggestions that Michael is making,
> keeping in
> > mind that he isn't obliged to do this at all.
> >
> 
> That's fine, it means that the "unfriendly emails" will continue.

Well, at some point, I think they should get moderated rather than responded.

sw