[FFmpeg-devel] Democratization work in progress draft v2

[Vittorio Giovara]

On Wed, Jan 29, 2025 at 10:49 PM Soft Works <
softworkz-at-hotmail.com at ffmpeg.org> wrote:

>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Leo
> > Izen
> > Sent: Wednesday, January 29, 2025 10:39 PM
> > To: ffmpeg-devel at ffmpeg.org
> > Subject: Re: [FFmpeg-devel] Democratization work in progress draft v2
> >
> > On 1/29/25 3:33 PM, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > Heres my current "work in progress": (sending that before fosdem,
> > so people can discuss if they like)
> > >
> > > Goals:
> > >      The proposed changes aim to improve the General Assembly's
> > structure to ensure inclusivity, fairness, and resilience against
> > attacks. The key goals are as follows:
> > >      Increase the Size of the General Assembly
> > >          Inclusivity: Allow every contributor to have a vote,
> > ensuring all voices are heard, regardless of their role or level of
> > involvement.
> > >          Enhanced Security: By increasing the number of voters, it
> > becomes significantly harder for a malicious actor or group to
> > influence decisions. A larger voting pool dilutes the impact of any
> > single attack or coordinated effort.
> > >      Make Voting Power Proportional to Contributions
> > >          Fair Representation: Allocate voting power based on
> > contributions, ensuring that those who dedicate substantial time and
> > effort to the project have a stronger voice than those with minimal
> > involvement. This creates a system where contribution equals
> > influence.
> > >          Resilience Against Attacks: Attackers would need not only
> > a large number of people but also a comparable volume of meaningful
> > contributions to influence the vote, further safeguarding the
> > project.
> > >          Motivating Participation: Encouraging higher levels of
> > engagement by rewarding contributors with more influence in decision-
> > making.
> > >      Broaden the Definition of Contributions
> > >          Previously everyone was a software developer. But really
> > there are many people in the community, who are not software
> > developers.
> > >
> > >
> > > Shares in Alternative P
> > >      1 release                               == 100 shares
> > >      1 entry in MAINTAINERS                  == 100 shares
> > >      1 commit in           git master branch ==  10 shares
> > >      1 subscription in ffmpeg-devel          ==  10 shares
> > >      1 subscription in ffmpeg-user           ==  10 shares
> > >      1 fixed ticket in trac                  ==  10 shares
> > >      1 reported issue in trac                ==   2 shares
> > >      1 mail in ffmpeg-devel                  ==   2 shares
> > >      1 mail in ffmpeg-user                   ==   2 shares
> > >      1 (backported) commit in release branch ==   1 shares
> > >
> >
> > I have been silent on this for a very long time, but I would like to
> > point out at this point that Michael has approximately five times as
> > many commits as the next-most prolific contributor (Andreas).
> >
> > (for those curious, navigate to git master and run: git shortlog -s -
> > n)
> >
> > If you draft language that gives you five times as much voting power
> > as
> > anybody else it does not realistically make it appear as though you
> > are
> > interested in handing over reigns to anybody.
>
> Am I the only one who has read that (probably so far most important)
> message where Michael has clearly said that such "handing over reigns" (he
> said "keys") is not going to happen as - would it burn down to that -
> people should rather fork?
>
> I think it's important to be clear about that, as it might save a lot of
> wasted energy.
>

We should be all running Windows XP, and never have switched away from
Monarchy after the French revolution, it might have saved a lot of wasted
energy.
-- 
Vittorio