[FFmpeg-devel] Democratization work in progress draft v2

[Niklas Haas]

On Wed, 29 Jan 2025 21:33:21 +0100 Michael Niedermayer <michael at niedermayer.cc> 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.

This should be time-gated to count only commits in the recent, say, 3 years (to
match the current GA cycle). Counting purely historical commits seems odd.

To use a loose analogy to a real-world democracy, it's like suggesting that
retirees should have more votes than young adults because they've lived in a
country for longer. This is a non sequitur - in reality, it should be, if
anything, the exact other way around. Those with a stake in the project's
present and future deserve more say than those with a stake purely in its past.

>         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
> 
>     If the condorcet vote software fails due to the number of shares then
>     all shares shall be divided by 2 before all rounding and non integer shares shall be rounded to nearest even
>     this shall be repeated until the vote software no longer fails due to the number.
> 
> Shares in Alternative F
>     Everyone who either has authored a commit in git master or sent a mail to ffmpeg-devel or user
>     or fixed or reported an issue in trac has exactly the same vote power. This is a true classical democracy.
>     It includes the nearly same people as the previous suggestion but without the
>     proportionality. It is vulnerable to a group of a few thousand actual people joining and coordinating
>     an attack. The proportionality raises the bar for such an attack by ~2 orders of magnitude.
> 
>     We need a list to remap multiple addresses to the same person (this is not needed for the proportional case)
> 
> Any single company collective vote power is limited to 10%, associated companies count as the same company here.
> 
> If anyone can show that specific activities are automated then the test used for detecting them
> shall by confirmed by GA vote and then be added to a list of anti-bot tests. This vote shall be
> performed by a GA that is on the closest first january prior to the event adding the disputed shares.
> 
> the list of mails on ffmpeg-devel and ffmpeg-user should be filtered by the current subscribers based on the
> idea that someone who left by choice does not want to receive vote mails. If they want to vote they can
> re-subcribe
> 
> In all cases, whenever possible decisions should be made by consensus on ffmpeg-devel.
> Voting should only be used when consensus was tried at least twice and failed
> 
> A factor related to last activity will be in a seperate vote
> A veto power may be in seperate vote
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Some Animals are More Equal Than Others. - George Orwell's book Animal Farm
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".