Re: [FFmpeg-devel] Democratization work in progress draft v2

[Vittorio Giovara <vittorio.giovara@gmail.com>]

On Wed, Jan 29, 2025 at 9:33 PM Michael Niedermayer <michael@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.
>         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
>

I'm sorry Micheal, but given you refuse to let the current governance run
its course, there is no guarantee that you won't change your mind again
after we implement this overengineered system, and we are back to square
one, resulting in a lot of wasted time and effort.

Either assume the dictator role like you're aspiring to do, causing people
to drop ffmpeg/leave foss/fork/whatever, or let the democratic process be
enacted, it's still not too late.

Therefore... NAK on the proposal.
-- 
Vittorio
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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