[FFmpeg-devel] Democratization work in progress draft v2

[FFmpeg-devel] Democratization work in progress draft v2

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 4185 bytes --]

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

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some Animals are More Equal Than Others. - George Orwell's book Animal Farm

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Leo Izen]

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.

- Leo Izen (Traneptora)

_______________________________________________
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".

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

[Nicolas George]

Leo Izen (12025-01-29):
> 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).

We can add that Michael's commits tend to be more complex.

This is precisely why Michael should be in charge.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

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

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Leo
> Izen
> Sent: Wednesday, January 29, 2025 10:39 PM
> To: ffmpeg-devel@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.

sw




_______________________________________________
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".

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

[Niklas Haas]

On Wed, 29 Jan 2025 21:33:21 +0100 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.

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@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe".

Re: [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@ffmpeg.org> wrote:

>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Leo
> > Izen
> > Sent: Wednesday, January 29, 2025 10:39 PM
> > To: ffmpeg-devel@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
_______________________________________________
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".

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

[Vittorio Giovara]

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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 4318 bytes --]

Hi Niklas

On Thu, Jan 30, 2025 at 12:43:13AM +0100, Niklas Haas wrote:
> On Wed, 29 Jan 2025 21:33:21 +0100 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.
> 
> 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.

Later in this text there is:
> > A factor related to last activity will be in a seperate vote


> 
> 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.

If instead of a hypothetical case, you use real cases
like for example any successfull company (not just on the stock market but that too)
(obviously we skip unsuccessfull companies)

Then we can see that the founders, and people that build the company up from near 0
and worked their whole life on it, made the right decissions early on to make the
company what it became often have a larger number of shares and thus vote power.

This method has been tested in the commercial world and it works.
But maybe someone has tried throwing all sharholders out and giving the
shares to only the recently active employees. Personally i think that would
most of the time end badly ...
(again iam using the example of a commercial company here because it has a
 clear way to judge success. I dont like the comparission either, FFmpeg is not
 a commercial entity and it will not become one)

A project that makes the wrong decissions fails. A project that makes the right
decissions the people making these decissions should be rewarded with more vote
power. FFmpeg under the GA has done poorly, there was no growth for example and
we had increasing infighting. So the idea that all power should rest only on that
group seems simply the wrong choice for FFmpeg to me. I think we should try
something else. Whatever is better is the new local minima and we keep trying
until we cannot improve anymore. Like trying to find the best motion vector
in motion estimation. Try good vectors from surroundings, then iterate with
smaller steps until optimum is found.

The GA system was tried for several years, IMO lets try something else
be that a Flat or Proportional system that includes the whole community.
Then try the other of the 2.

If everything fails we can also try a
benevolent Dictator model again. But for that really it requires the
community to want that, iam not interrested in this with a 51% majority
behind me. It would need a much stronger majority like 70+%

Also my proposal contained "Shares in Alternative F"
where everyone has a equal share (F for flat)

In the flat system i would have 1 vote in thousands. But also everyone else
would only have 1 vote.


thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Give a rich man 100$ and he will turn it into 1000$.
Give a poor man 1000$ and he will spend it.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Nicolas George]

Michael Niedermayer (12025-01-30):
> If instead of a hypothetical case, you use real cases
> like for example any successfull company (not just on the stock market
> but that too)

If we compare ffmpeg to a company (a dangerous comparison, as the goals
of FFmpeg are quite different, but let us roll with it, and it is ma
much better comparison than with a country), we should compare it to a
small one, not a large one.

And in a small company, as far as I know, employees do not usually get a
say in the direction automatically. The founder keeps all the power,
until they cede it to a successor.

Small companies and small Libre Software projects are too vulnerable to
a takeover by a small number of greedy people who care about what they
can gain from it more than the well-being of the company/project.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

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

[Nicolas George]

Niklas Haas (12025-01-30):
> 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.

On the other hand, we should give more weight to the opinion of people
who have been around for many years and obviously intend to stay than to
the opinion of people who have been here for a few months and will leave
after two or three job missions.

Past involvement, including long-past involvement, is not only past, it
is both indication of knowledge about the project and prediction of
future involvement.

For that reason, I believe that if this plan goes forward, it should
include all past involvement, but possibly with the condition that the
involvement continues presently.

On the other hand, I believe this whole plan is a bad idea.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

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

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 2098 bytes --]

On 1/31/2025 11:58 AM, Nicolas George wrote:
> Niklas Haas (12025-01-30):
>> 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.
> 
> On the other hand, we should give more weight to the opinion of people
> who have been around for many years and obviously intend to stay than to
> the opinion of people who have been here for a few months and will leave
> after two or three job missions.

Is this level of discredit necessary or useful for the discussion? And 
how many people have met the requisites after only a few months of 
contributions before leaving? Not to mention the GA does not get updated 
on the fly, but gets refreshed in specific intervals, so anyone who just 
dumps some code then leaves immediately is unlikely to even make it in, 
and if they do, they'd barely last.

> 
> Past involvement, including long-past involvement, is not only past, it
> is both indication of knowledge about the project and prediction of
> future involvement.
> 
> For that reason, I believe that if this plan goes forward, it should
> include all past involvement, but possibly with the condition that the
> involvement continues presently.

This we all agree with. If someone has contributed code a long time ago 
and wants a voice, they should at least be active in some form. It's the 
case of a few proposed GA additions that did not met the commit criteria 
and were then accepted.

> 
> On the other hand, I believe this whole plan is a bad idea.
Yes, it is a bad idea. We have had the current system in place for about 
five years now, and besides one or two CC assemblages being inefficient, 
it has worked. Changing it now because one person was unhappy with a CC 
(That was literally on the way out, in fact) sets a bad precedent, 
because then anyone that dislikes agreed decisions will want to redo 
everything from scratch in the hopes a new system will be more to their 
liking, and the bikesheding and filibustering will never end.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> James Almer
> Sent: Friday, January 31, 2025 4:45 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Democratization work in progress draft v2
> 
> > Past involvement, including long-past involvement, is not only
> past, it
> > is both indication of knowledge about the project and prediction of
> > future involvement.
> >
> > For that reason, I believe that if this plan goes forward, it
> should
> > include all past involvement, but possibly with the condition that
> the
> > involvement continues presently.

How about a quadratic attenuation of past commit counts, so that older commits count less than more recent ones?

Here are some examples with different base values:

+------+-----+-----------------------------------+
| Year | Y-T |                Base               |
+------+-----+------+-------+------+------+------+
|      |     | 0.85 | 0.825 |  0.8 | 0.75 |  0.7 |
+------+-----+------+-------+------+------+------+
| 2023 |   0 | 100% |  100% | 100% | 100% | 100% |
+------+-----+------+-------+------+------+------+
| 2022 |  -1 |  85% |   83% |  80% |  75% |  70% |
+------+-----+------+-------+------+------+------+
| 2021 |  -2 |  72% |   68% |  64% |  56% |  49% |
+------+-----+------+-------+------+------+------+
| 2020 |  -3 |  61% |   56% |  51% |  42% |  34% |
+------+-----+------+-------+------+------+------+
| 2019 |  -4 |  52% |   46% |  41% |  32% |  24% |
+------+-----+------+-------+------+------+------+
| 2018 |  -5 |  44% |   38% |  33% |  24% |  17% |
+------+-----+------+-------+------+------+------+
| 2017 |  -6 |  38% |   32% |  26% |  18% |  12% |
+------+-----+------+-------+------+------+------+
| 2016 |  -7 |  32% |   26% |  21% |  13% |   8% |
+------+-----+------+-------+------+------+------+
| 2015 |  -8 |  27% |   21% |  17% |  10% |   6% |
+------+-----+------+-------+------+------+------+
| 2014 |  -9 |  23% |   18% |  13% |   8% |   4% |
+------+-----+------+-------+------+------+------+
| 2013 | -10 |  20% |   15% |  11% |   6% |   3% |
+------+-----+------+-------+------+------+------+
| 2012 | -11 |  17% |   12% |   9% |   4% |   2% |
+------+-----+------+-------+------+------+------+
| 2011 | -12 |  14% |   10% |   7% |   3% |   1% |
+------+-----+------+-------+------+------+------+
| 2010 | -13 |  12% |    8% |   5% |   2% |   1% |
+------+-----+------+-------+------+------+------+
| 2009 | -14 |  10% |    7% |   4% |   2% |   1% |
+------+-----+------+-------+------+------+------+
| 2008 | -15 |   9% |    6% |   4% |   1% |   0% |
+------+-----+------+-------+------+------+------+
| 2007 | -16 |   7% |    5% |   3% |   1% |   0% |
+------+-----+------+-------+------+------+------+
| 2006 | -17 |   6% |    4% |   2% |   1% |   0% |
+------+-----+------+-------+------+------+------+
| 2005 | -18 |   5% |    3% |   2% |   1% |   0% |
+------+-----+------+-------+------+------+------+
| 2004 | -19 |   5% |    3% |   1% |   0% |   0% |
+------+-----+------+-------+------+------+------+
| 2003 | -20 |   4% |    2% |   1% |   0% |   0% |
+------+-----+------+-------+------+------+------+

sw
_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1485 bytes --]

Hi James

On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote:
> On 1/31/2025 11:58 AM, Nicolas George wrote:
> > Niklas Haas (12025-01-30):
[...]
> > On the other hand, I believe this whole plan is a bad idea.
> Yes, it is a bad idea. We have had the current system in place for about
> five years now, and besides one or two CC assemblages being inefficient, it

Do you remember this suggested addition to the FAQ ?
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html

It seems you dont remember it even though this was posted just a few days ago
I knew this is needed to be put in the FAQ ;(


> has worked. Changing it now because one person was unhappy with a CC (That

This is a false statement. Iam not suggesting a change to the GA because of one CC
iam suggesting a change because it is vulnerable to an attack.

(The CC isnt even fixed by this, i think the concept of a CC elected out of a
community thats full of mutual hate is a bad idea)

But back to the topic, what do you suggest to fix the vulerability in the GA ?
Or you dont care?

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Zhao Zhili]

> On Feb 1, 2025, at 08:49, Michael Niedermayer <michael@niedermayer.cc> wrote:
> 
> Hi James
> 
> On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote:
>> On 1/31/2025 11:58 AM, Nicolas George wrote:
>>> Niklas Haas (12025-01-30):
> [...]
>>> On the other hand, I believe this whole plan is a bad idea.
>> Yes, it is a bad idea. We have had the current system in place for about
>> five years now, and besides one or two CC assemblages being inefficient, it
> 
> Do you remember this suggested addition to the FAQ ?
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html
> 

The proposal treat every GA member as suspect, and GA members with daily jobs guilty.

The community should be based on trust and everyone should be trust equally, unless
he/she did something not worth the trust. The 20 patches threshold for GA is a prove
of basic understanding of the project and the willingness to participate, not means
someone with more patches has more weight when vote on community activities.

It’s dangerous to fix the vulnerability in the GA by make GA totally under control, which
makes the concept of GA useless. Vote doesn't means truth, it’s a method of feedback
control. Open loop control without feedback works for simple system, it’s not reliable
and sustainable for complex system.Trust every GA members unless it is proven that
someone has been bribed. FFmpeg project is invaluable and I cherish my right to
vote, but I don’t believe there is anyone want to buy the right to vote.

> It seems you dont remember it even though this was posted just a few days ago
> I knew this is needed to be put in the FAQ ;(
> 
> 
>> has worked. Changing it now because one person was unhappy with a CC (That
> 
> This is a false statement. Iam not suggesting a change to the GA because of one CC
> iam suggesting a change because it is vulnerable to an attack.
> 
> (The CC isnt even fixed by this, i think the concept of a CC elected out of a
> community thats full of mutual hate is a bad idea)
> 
> But back to the topic, what do you suggest to fix the vulerability in the GA ?
> Or you dont care?
> 
> thx
> 
> [...]
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> If you drop bombs on a foreign country and kill a hundred thousand
> innocent people, expect your government to call the consequence
> "unprovoked inhuman terrorist attacks" and use it to justify dropping
> more bombs and killing more people. The technology changed, the idea is old.
> _______________________________________________
> 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".

_______________________________________________
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".

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

[Ronald S. Bultje]

Hi,

On Sat, Feb 1, 2025 at 1:45 AM Zhao Zhili <
quinkblack-at-foxmail.com@ffmpeg.org> wrote:

> The proposal treat every GA member as suspect, and GA members with daily
> jobs guilty.


Thank you for saying this. I couldn't agree more.

Ronald
_______________________________________________
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".

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

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 2012 bytes --]

On 1/31/2025 9:49 PM, Michael Niedermayer wrote:
> Hi James
> 
> On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote:
>> On 1/31/2025 11:58 AM, Nicolas George wrote:
>>> Niklas Haas (12025-01-30):
> [...]
>>> On the other hand, I believe this whole plan is a bad idea.
>> Yes, it is a bad idea. We have had the current system in place for about
>> five years now, and besides one or two CC assemblages being inefficient, it
> 
> Do you remember this suggested addition to the FAQ ?
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html
> 
> It seems you dont remember it even though this was posted just a few days ago
> I knew this is needed to be put in the FAQ ;(

I saw it, and i think that patch is anything but objective and 
completely unacceptable. You're stating your opinion and discrediting a 
system in an official document in the project's repository itself of all 
places. Do you not see how absurd that is?

> 
> 
>> has worked. Changing it now because one person was unhappy with a CC (That
> 
> This is a false statement. Iam not suggesting a change to the GA because of one CC
> iam suggesting a change because it is vulnerable to an attack.
> 
> (The CC isnt even fixed by this, i think the concept of a CC elected out of a
> community thats full of mutual hate is a bad idea)
> 
> But back to the topic, what do you suggest to fix the vulerability in the GA ?
> Or you dont care?

Why do you say there's a vulnerability in the GA? Has it been exploited 
for this to be an issue? Did someone to your knowledge buy a developer 
to write 20 commits and get them into the GA? Otherwise, you're making a 
big deal out of an hypothetical, and that's really damaging to the project.

I don't know if you realize, but you're being incredibly disrespectful 
with almost everyone who has contributed anything in the last decade, 
treating them as moles trying to bring down the project instead of 
contributing to its success.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Jean-Baptiste Kempf]

Hello,

On Sat, 1 Feb 2025, at 07:45, Zhao Zhili wrote:
> The proposal treat every GA member as suspect, and GA members with 
> daily jobs guilty.
>
> The community should be based on trust and everyone should be trust 
> equally, 

+1 

> It’s dangerous to fix the vulnerability in the GA by make GA totally 
> under control, which

I agree with you Zhao, and everything you said.

jbk

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
https://jbkempf.com/
_______________________________________________
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".

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

[Vittorio Giovara]

Sent from my iPhone

> On Feb 1, 2025, at 2:21 PM, Ronald S. Bultje <rsbultje@gmail.com> wrote:
> 
> Hi,
> 
>> On Sat, Feb 1, 2025 at 1:45 AM Zhao Zhili <
>> quinkblack-at-foxmail.com@ffmpeg.org> wrote:
>> 
>> The proposal treat every GA member as suspect, and GA members with daily
>> jobs guilty.
> 
> 
> Thank you for saying this. I couldn't agree more.

+1
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".

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

[Vittorio Giovara]

Sent from my iPhone

> On Feb 1, 2025, at 3:11 PM, Jean-Baptiste Kempf <jb@videolan.org> wrote:
> 
> Hello,
> 
>> On Sat, 1 Feb 2025, at 07:45, Zhao Zhili wrote:
>> The proposal treat every GA member as suspect, and GA members with
>> daily jobs guilty.
>> 
>> The community should be based on trust and everyone should be trust
>> equally,
> 
> +1
> 
>> It’s dangerous to fix the vulnerability in the GA by make GA totally
>> under control, which
> 
> I agree with you Zhao, and everything you said.

+1 here too ofc
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".

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

[Nicolas George]

Michael Niedermayer (12025-01-29):
> Hi all
> 
> Heres my current "work in progress": (sending that before fosdem, so people can discuss if they like)

Counter-proposal:

By any sane measure of merit towards the project you would get more
votes than anybody else, that makes no sense. So, instead, you get 0
vote because you do not take part in the votes, you organize them.

You are officially the leader of the project, and as such the arbiter of
consensus among the community. You hold that role preferably by judging
the arguments, or more frequently by delegating that task to
maintainers, but if the arguments fail to convince, you can decide to
hold a vote.

You decide on the voting body and the weight of each voter according to
the merit criteria of your choice. You do not make them public so as not
to trigger Goodhart's law. You should experiment with variations on the
criteria and see if they lead to a significant difference in result, and
see which variation most match your subjective assessment of people's
merit.

The votes are public. Mandatory secrecy is not possible with online
votes and voluntary secrecy is not important in this case.

People have to trust you about the results. If they do not trust the
leader, they can work on something else.

You are free to delegate any of these tasks in order to be able to focus
on more interesting things.

Peace on the mailing-list is also your duty as leader and arbiter of the
consensus among the community. You should delegate that duty to a team
of trusted moderators, same as maintainers. You can seek consensus to
choose them, using a vote if necessary.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1875 bytes --]

Hi James

On Sat, Feb 01, 2025 at 10:30:21AM -0300, James Almer wrote:
> On 1/31/2025 9:49 PM, Michael Niedermayer wrote:
> > Hi James
> > 
> > On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote:
> > > On 1/31/2025 11:58 AM, Nicolas George wrote:
> > > > Niklas Haas (12025-01-30):
> > [...]
> > > > On the other hand, I believe this whole plan is a bad idea.
> > > Yes, it is a bad idea. We have had the current system in place for about
> > > five years now, and besides one or two CC assemblages being inefficient, it
> > 
> > Do you remember this suggested addition to the FAQ ?
> > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html
> > 
> > It seems you dont remember it even though this was posted just a few days ago
> > I knew this is needed to be put in the FAQ ;(
> 
> I saw it, and i think that patch is anything but objective and completely
> unacceptable. You're stating your opinion and discrediting a system in an
> official document in the project's repository itself of all places. Do you
> not see how absurd that is?

The system is absurd, the text points this out in a mocking/ironic way.
If you want me to reword this in a dry formal way, i can submit such a patch?

If not, how do you suggest we move forward here ?
We can replace the GA by a system that is not vulnerable
We can treat the GA more as guidance and not a final authority
We can publish the issue and warn our users and leave it vulnerable
We can try to block every choice, and treat this like any "publish after 90day"
   security issue (ffmpeg community refuses to fix or publish)

will reply to the 2nd part seperately

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2672 bytes --]

Hi James

On Sat, Feb 01, 2025 at 10:30:21AM -0300, James Almer wrote:
> On 1/31/2025 9:49 PM, Michael Niedermayer wrote:
[...]
> >
> > 
> > > has worked. Changing it now because one person was unhappy with a CC (That
> > 
> > This is a false statement. Iam not suggesting a change to the GA because of one CC
> > iam suggesting a change because it is vulnerable to an attack.
> > 
> > (The CC isnt even fixed by this, i think the concept of a CC elected out of a
> > community thats full of mutual hate is a bad idea)
> > 
> > But back to the topic, what do you suggest to fix the vulerability in the GA ?
> > Or you dont care?
> 
> Why do you say there's a vulnerability in the GA?

The FAQ describes how to exploit it. And i belive others independantly found
this issue as well.


> Has it been exploited for

Given the nature of this vulerability, its very hard to detect it being exploited


> this to be an issue?

While active eploitation, certainly makes an issue worse. In general and
especially when exploitation is not detectable, this is something we cannot wait for


> Did someone to your knowledge buy a developer to write
> 20 commits and get them into the GA?

Lets be carefull here with the words. But the awnser is "yes"
Many developers have been paid to write commits. employees, contractors, students

Do i know of someone being asked after that to vote in a specific way ?
No, how could i know other peoples private communication

Have people asked me how/if they should vote ?
Yes, some people did ask.

In general "few time" outside contributors being payed to do some work dont
care about the votes, they come, do some work and leave.
I would expect the random subscriber of 2000 on ffmpeg-devel to care more
as they follow the list for a long term they care more about the consequences


> Otherwise, you're making a big deal out
> of an hypothetical, and that's really damaging to the project.
> 

> I don't know if you realize, but you're being incredibly disrespectful with
> almost everyone who has contributed anything in the last decade, treating
> them as moles trying to bring down the project instead of contributing to
> its success.

I would appreciate if you keep this emotional drama out. We need to look
with a clear head at this. Noone is disrespectful to people using ssh if
ssh is vulnerable.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Kieran Kunhya via ffmpeg-devel]

Hi Michael,

On Sat, 1 Feb 2025, 22:27 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

>
> Lets be carefull here with the words. But the awnser is "yes"
> Many developers have been paid to write commits. employees, contractors,
> students
>

As an FFlabs employee (which I believe is the biggest GA cohort) and
shareholder are you aware of anyone in your company instructing people to
vote a certain way?

Kieran
_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2083 bytes --]

Hi Nicolas

On Sat, Feb 01, 2025 at 09:44:50PM +0100, Nicolas George wrote:
> Michael Niedermayer (12025-01-29):
> > Hi all
> > 
> > Heres my current "work in progress": (sending that before fosdem, so people can discuss if they like)
> 
> Counter-proposal:
> 
> By any sane measure of merit towards the project you would get more
> votes than anybody else, that makes no sense. So, instead, you get 0
> vote because you do not take part in the votes, you organize them.
> 
> You are officially the leader of the project, and as such the arbiter of
> consensus among the community. You hold that role preferably by judging
> the arguments, or more frequently by delegating that task to
> maintainers, but if the arguments fail to convince, you can decide to
> hold a vote.
> 
> You decide on the voting body and the weight of each voter according to
> the merit criteria of your choice. You do not make them public so as not
> to trigger Goodhart's law. You should experiment with variations on the
> criteria and see if they lead to a significant difference in result, and
> see which variation most match your subjective assessment of people's
> merit.
> 
> The votes are public. Mandatory secrecy is not possible with online
> votes and voluntary secrecy is not important in this case.
> 
> People have to trust you about the results. If they do not trust the
> leader, they can work on something else.
> 
> You are free to delegate any of these tasks in order to be able to focus
> on more interesting things.
> 
> Peace on the mailing-list is also your duty as leader and arbiter of the
> consensus among the community. You should delegate that duty to a team
> of trusted moderators, same as maintainers. You can seek consensus to
> choose them, using a vote if necessary.

This is an interresting proposal.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Leo Izen]

On 1/31/25 11:01 AM, Soft Works wrote:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> James Almer
>> Sent: Friday, January 31, 2025 4:45 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] Democratization work in progress draft v2
>>
>>> Past involvement, including long-past involvement, is not only
>> past, it
>>> is both indication of knowledge about the project and prediction of
>>> future involvement.
>>>
>>> For that reason, I believe that if this plan goes forward, it
>> should
>>> include all past involvement, but possibly with the condition that
>> the
>>> involvement continues presently.
> 
> How about a quadratic attenuation of past commit counts, so that older commits count less than more recent ones?
> 

Such quadratic metrics tend to be such that for currently active 
contributors, it roughly correlates with square root of commit count 
(which is an increasing function) and therefore isn't meaningfully 
different.

A similar thing was discovered in the N-papers-cited-N-times-each metric 
which was popular at one point in academia as an alternative to citation 
count. It turned out to maximize the area of an axis-bounded square when 
contributions were plotted, which is why for naturally occurring data it 
correlated pretty well with the square root of total citation count.

While this isn't an entirely analogous situation, most contributors who 
are active have been active since they started contributing, so this 
doesn't do a whole lot except to pick out people who used to be active 
and then stopped and then started up again.

- Leo Izen (Traneptora)

_______________________________________________
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".

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

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Leo
> Izen
> Sent: Sunday, February 2, 2025 3:26 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Democratization work in progress draft v2
> 
> On 1/31/25 11:01 AM, Soft Works wrote:

[..]

Hi Leo,

> > How about a quadratic attenuation of past commit counts, so that
> older commits count less than more recent ones?

Shortly after sending I realized that it's exponential, not quadratic (which was the initial idea), sorry for the mixup.

> Such quadratic metrics tend to be such that for currently active
> contributors, it roughly correlates with square root of commit count
> (which is an increasing function) and therefore isn't meaningfully
> different.

I'm not sure whether I can follow. Do you mean for 

1. currently active contributors who have been active in the past
2. currently active contributors who have not been active in the past
3. for both equally?

If you mean that it's equal for all in (1), that would be just like intended as the goal would be to give them more voting power than those in (2).
It would also give those a vote who have contributed in the past but are no longer active, yet decreasing over time.


> A similar thing was discovered in the N-papers-cited-N-times-each
> metric
> which was popular at one point in academia as an alternative to
> citation
> count. It turned out to maximize the area of an axis-bounded square
> when
> contributions were plotted, which is why for naturally occurring data
> it
> correlated pretty well with the square root of total citation count.
> 
> While this isn't an entirely analogous situation, most contributors
> who
> are active have been active since they started contributing, 
> so this
> doesn't do a whole lot except to pick out people who used to be
> active
> and then stopped and then started up again.

I'm not sure how it was done in the case you are referring to, but it sounds like the time axis there would have been scaled  to the begin of their activity, while in this case, it would be absolute.

(please correct me if I'm misinterpreting)

Also, in the academic area, one usually doesn't stop activity like it happens in case of ffmpeg, for which one would be given decreasing weight of votes over time.


I'm not actually proposing this as a model, but some had said that contributions from past times (earlier than the 3-yr GA range) should give them more weight in voting, and my answer to that is, if this would be done, then it should be at least in a way that recent contributions will count more than older contributions.

What was the outcome in the academic world - back to citation count?

Best
sw


_______________________________________________
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".

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

[Vittorio Giovara]

On Sun, Feb 2, 2025 at 3:26 AM Leo Izen <leo.izen@gmail.com> wrote:

> While this isn't an entirely analogous situation, most contributors who
> are active have been active since they started contributing, so this
> doesn't do a whole lot except to pick out people who used to be active
> and then stopped and then started up again.
>

I'd assume that's exactly the point, in this way a lot of uninformed people
can come back from the past and they can be more easily manipulated to sway
the community opinion or directly skew the vote, without having any idea
what they are talking about. It's the same stuff that happened in mplayer
days, same old same old.
-- 
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2158 bytes --]

Hi

On Sat, Feb 01, 2025 at 02:45:26PM +0800, Zhao Zhili wrote:
> 
> 
> > On Feb 1, 2025, at 08:49, Michael Niedermayer <michael@niedermayer.cc> wrote:
> > 
> > Hi James
> > 
> > On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote:
> >> On 1/31/2025 11:58 AM, Nicolas George wrote:
> >>> Niklas Haas (12025-01-30):
> > [...]
> >>> On the other hand, I believe this whole plan is a bad idea.
> >> Yes, it is a bad idea. We have had the current system in place for about
> >> five years now, and besides one or two CC assemblages being inefficient, it
> > 
> > Do you remember this suggested addition to the FAQ ?
> > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html
> > 
> 
> The proposal treat every GA member as suspect, and GA members with daily jobs guilty.

The text i proposed for the FAQ was intended to raise the issue with an humours tone
and wasnt meant to be taken litteral.


> 
> The community should be based on trust and everyone should be trust equally, unless
> he/she did something not worth the trust. The 20 patches threshold for GA is a prove
> of basic understanding of the project and the willingness to participate, not means
> someone with more patches has more weight when vote on community activities.

yes but its not so simple

Open source projects have increasingly become the target for supply chain attacks.
In some cases multiple people over year long periods have participated in such attacks

If we look at governance in democratic countries. Vote buying has repeatly happened.

If we look at governance in crypto. hundreds of millions where stolen through
governance attacks.

(you can find examples for above by asking chatgpt or a search engine)

FFmpeg is used by billions of people indirectly, we are not a small unimportant
project that noone cares about.

I think, its dangerous for us to say, "it will not happen to us"
its safer to make the system more robust

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some Animals are More Equal Than Others. - George Orwell's book Animal Farm

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 3006 bytes --]

On 2/1/2025 6:53 PM, Michael Niedermayer wrote:
> Hi James
> 
> On Sat, Feb 01, 2025 at 10:30:21AM -0300, James Almer wrote:
>> On 1/31/2025 9:49 PM, Michael Niedermayer wrote:
>>> Hi James
>>>
>>> On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote:
>>>> On 1/31/2025 11:58 AM, Nicolas George wrote:
>>>>> Niklas Haas (12025-01-30):
>>> [...]
>>>>> On the other hand, I believe this whole plan is a bad idea.
>>>> Yes, it is a bad idea. We have had the current system in place for about
>>>> five years now, and besides one or two CC assemblages being inefficient, it
>>>
>>> Do you remember this suggested addition to the FAQ ?
>>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html
>>>
>>> It seems you dont remember it even though this was posted just a few days ago
>>> I knew this is needed to be put in the FAQ ;(
>>
>> I saw it, and i think that patch is anything but objective and completely
>> unacceptable. You're stating your opinion and discrediting a system in an
>> official document in the project's repository itself of all places. Do you
>> not see how absurd that is?
> 
> The system is absurd

The system is fine. One CC was inefficient and it bothered you to the 
point you want to start everything from scratch. It's not reasonable.

, the text points this out in a mocking/ironic way.
> If you want me to reword this in a dry formal way, i can submit such a patch?
> 
> If not, how do you suggest we move forward here ?
> We can replace the GA by a system that is not vulnerable

I ask again, do you have any reason other than an hypothetical scenario 
to think the GA is vulnerable? Or can you mention a point during the 
last five years where any such a vulnerability was taken advantage of?

Shit happened with xz, and now every contributor in FOSS is a suspect? 
You handle the releases, including git tags and tarballs. There's no way 
something like that could happen here. And unlike the people that 
infiltrated that project, everyone here who's active and has access to 
some part of the infrastructure has a very public presence online and 
most even offline in plenty of events and conventions. Not to mention, 
nothing the GA could vote for would even remotely result in someone 
being able to do something like the xz tarball hijack.

If commit access is something you worry about, once we move to 
Gitlab/Forgejo, we can limit the people with MR merging permissions to 
strictly only those in Maintainers. And release/tagging can be further 
limited to only you, to keep things as is.

> We can treat the GA more as guidance and not a final authority

This is trying to declare that an agreed upon system in place will no 
longer be valid because you're not satisfied with how one part of it 
behaved. And if the GA becomes guidance, who or what will be the final 
authority? If it turns out to be a "who", then we'd not be dealing with 
a community managed project anymore.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 3791 bytes --]

On 2/1/2025 7:27 PM, Michael Niedermayer wrote:
> Hi James
> 
> On Sat, Feb 01, 2025 at 10:30:21AM -0300, James Almer wrote:
>> On 1/31/2025 9:49 PM, Michael Niedermayer wrote:
> [...]
>>>
>>>
>>>> has worked. Changing it now because one person was unhappy with a CC (That
>>>
>>> This is a false statement. Iam not suggesting a change to the GA because of one CC
>>> iam suggesting a change because it is vulnerable to an attack.
>>>
>>> (The CC isnt even fixed by this, i think the concept of a CC elected out of a
>>> community thats full of mutual hate is a bad idea)
>>>
>>> But back to the topic, what do you suggest to fix the vulerability in the GA ?
>>> Or you dont care?
>>
>> Why do you say there's a vulnerability in the GA?
> 
> The FAQ describes how to exploit it. And i belive others independantly found
> this issue as well.
> 
> 
>> Has it been exploited for
> 
> Given the nature of this vulerability, its very hard to detect it being exploited
> 
> 
>> this to be an issue?
> 
> While active eploitation, certainly makes an issue worse. In general and
> especially when exploitation is not detectable, this is something we cannot wait for
> 
> 
>> Did someone to your knowledge buy a developer to write
>> 20 commits and get them into the GA?
> 
> Lets be carefull here with the words. But the awnser is "yes"
> Many developers have been paid to write commits. employees, contractors, students
> 
> Do i know of someone being asked after that to vote in a specific way ?
> No, how could i know other peoples private communication
> 
> Have people asked me how/if they should vote ?
> Yes, some people did ask.
> 
> In general "few time" outside contributors being payed to do some work dont
> care about the votes, they come, do some work and leave.
> I would expect the random subscriber of 2000 on ffmpeg-devel to care more
> as they follow the list for a long term they care more about the consequences

But what are the chances they'd get into the GA? Few-times outside 
contributors rarely submit more than a couple patches to implement the 
work they were paid for to do. Hardly 20 commits.
And we could always stop asking people to split their patches into 
several different smaller patches (cosmetics, refactoring, etc) to 
reduce the chances of one time contributors from meeting the GA 
requirements.

Looking at the current GA, do you see anyone in it who wrote code for 
their employer, met the requirements, and stopped being active after 
their work was upstreamed?

> 
> 
>> Otherwise, you're making a big deal out
>> of an hypothetical, and that's really damaging to the project.
>>
> 
>> I don't know if you realize, but you're being incredibly disrespectful with
>> almost everyone who has contributed anything in the last decade, treating
>> them as moles trying to bring down the project instead of contributing to
>> its success.
> 
> I would appreciate if you keep this emotional drama out. We need to look
> with a clear head at this. Noone is disrespectful to people using ssh if
> ssh is vulnerable.

It's not emotional drama, it's a fact. By your own admission you 
consider the GA, composed of almost every currently active developer, 
untrustworthy, vulnerable and in need to be scrapped or repurposed, with 
nothing to back that distrust other than hypotheticals about being an 
attack vector. Is that not being disrespectful to the people in it?

A potential "attack" to the GA can be worked around, as exemplified 
above. To request a complete redo of the system, arguments and actual 
events with considerable weight are needed. Otherwise, as i mentioned 
before, it will be perceived as someone asking for changes because they 
are unsatisfied.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Ronald S. Bultje]

Michael,

On Sat, Feb 1, 2025 at 4:53 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> The system is absurd, the text points this out in a mocking/ironic way.
> If you want me to reword this in a dry formal way, i can submit such a
> patch?
>

Every system is absurd. "If everyone just agreed with me, then ..." There
are no perfect systems. If there were, everyone would use it.


> If not, how do you suggest we move forward here ?
> We can replace the GA by a system that is not vulnerable
> We can treat the GA more as guidance and not a final authority
> We can publish the issue and warn our users and leave it vulnerable
> We can try to block every choice, and treat this like any "publish after
> 90day"
>    security issue (ffmpeg community refuses to fix or publish)
>

We could also do nothing.

Ronald
_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2989 bytes --]

Hi James

On Sun, Feb 02, 2025 at 03:14:58PM -0300, James Almer wrote:
> On 2/1/2025 6:53 PM, Michael Niedermayer wrote:
> > Hi James
> > 
> > On Sat, Feb 01, 2025 at 10:30:21AM -0300, James Almer wrote:
> > > On 1/31/2025 9:49 PM, Michael Niedermayer wrote:
> > > > Hi James
> > > > 
> > > > On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote:
> > > > > On 1/31/2025 11:58 AM, Nicolas George wrote:
> > > > > > Niklas Haas (12025-01-30):
> > > > [...]
> > > > > > On the other hand, I believe this whole plan is a bad idea.
> > > > > Yes, it is a bad idea. We have had the current system in place for about
> > > > > five years now, and besides one or two CC assemblages being inefficient, it
> > > > 
> > > > Do you remember this suggested addition to the FAQ ?
> > > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html
> > > > 
> > > > It seems you dont remember it even though this was posted just a few days ago
> > > > I knew this is needed to be put in the FAQ ;(
> > > 
> > > I saw it, and i think that patch is anything but objective and completely
> > > unacceptable. You're stating your opinion and discrediting a system in an
> > > official document in the project's repository itself of all places. Do you
> > > not see how absurd that is?
> > 
> > The system is absurd
> 
> The system is fine.

Then lets publish the FAQ i suggested (or a more formal text)
and let the reader judge it themselfs


> One CC was inefficient

It is not just one CC. And i would not choose the word "inefficient"


> and it bothered you

that really misses the point.

The CCs block moderators while allowing false statments to be published about
developers.
Its damaging to the people that are targetet and it created confusion and
disagreement where there is likely no actual significant disagreement
There are also several other serious issues with the CCs
(No public reporting / yearly reports / feedback to the voter)
(biased, treating some people differently)
(some CC members participated in attacks, both before and
 during their membership)
(some CC members did little, but no public reporting)
(one CC member called multiple developers assholes - then resigned
 - then was a candidates again - then resigned again)
...
And also iam happy to provide full references in public to any claim above


> to the point
> you want to start everything from scratch. It's not reasonable.

No, these are 2 seperate issues. The GA changes likely would not even fix
the CC issues.

Ill reply to the rest seperately to keep my replies short

thx

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Vittorio Giovara]

On Mon, Feb 3, 2025 at 7:08 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi James
>
> On Sun, Feb 02, 2025 at 03:14:58PM -0300, James Almer wrote:
> > On 2/1/2025 6:53 PM, Michael Niedermayer wrote:
> > > Hi James
> > >
> > > On Sat, Feb 01, 2025 at 10:30:21AM -0300, James Almer wrote:
> > > > On 1/31/2025 9:49 PM, Michael Niedermayer wrote:
> > > > > Hi James
> > > > >
> > > > > On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote:
> > > > > > On 1/31/2025 11:58 AM, Nicolas George wrote:
> > > > > > > Niklas Haas (12025-01-30):
> > > > > [...]
> > > > > > > On the other hand, I believe this whole plan is a bad idea.
> > > > > > Yes, it is a bad idea. We have had the current system in place
> for about
> > > > > > five years now, and besides one or two CC assemblages being
> inefficient, it
> > > > >
> > > > > Do you remember this suggested addition to the FAQ ?
> > > > >
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html
> > > > >
> > > > > It seems you dont remember it even though this was posted just a
> few days ago
> > > > > I knew this is needed to be put in the FAQ ;(
> > > >
> > > > I saw it, and i think that patch is anything but objective and
> completely
> > > > unacceptable. You're stating your opinion and discrediting a system
> in an
> > > > official document in the project's repository itself of all places.
> Do you
> > > > not see how absurd that is?
> > >
> > > The system is absurd
> >
> > The system is fine.
>
> Then lets publish the FAQ i suggested (or a more formal text)
> and let the reader judge it themselfs
>

Micheal, in the previous mail you said you were humorous, now you're saying
you are serious?
Is it a reverse VDD "joke" image posted on social networks?
It's really hard to read your mind, and this back and forth is not helpful,
and this filibustering is harming the project more than any updated
governance could provide.


> > One CC was inefficient
>
> It is not just one CC. And i would not choose the word "inefficient"
>

Sorry, I'm not following, how many CCs were there? 🤔

> and it bothered you
>
> that really misses the point.
>
> The CCs block moderators while allowing false statments to be published
> about
> developers.
> Its damaging to the people that are targetet and it created confusion and
> disagreement where there is likely no actual significant disagreement
> There are also several other serious issues with the CCs
> (No public reporting / yearly reports / feedback to the voter)
> (biased, treating some people differently)
> (some CC members participated in attacks, both before and
>  during their membership)
> (some CC members did little, but no public reporting)
> (one CC member called multiple developers assholes - then resigned
>  - then was a candidates again - then resigned again)
> ...
> And also iam happy to provide full references in public to any claim above
>

Are those "false statements" or "things people disagree with me"?

Some mailing list admins abused their power but they are still instated.
You know what would fix that? That's right, a working CC!


> > to the point
> > you want to start everything from scratch. It's not reasonable.
>
> No, these are 2 seperate issues. The GA changes likely would not even fix
> the CC issues.
>

Then what are we talking about...?


> Ill reply to the rest seperately to keep my replies short
>

Thank you, it is appreciated
-- 
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1773 bytes --]

Hi

On Sun, Feb 02, 2025 at 03:14:58PM -0300, James Almer wrote:
> On 2/1/2025 6:53 PM, Michael Niedermayer wrote:
> > Hi James
> > 
> > On Sat, Feb 01, 2025 at 10:30:21AM -0300, James Almer wrote:
> > > On 1/31/2025 9:49 PM, Michael Niedermayer wrote:
[...]
> , the text points this out in a mocking/ironic way.
> > If you want me to reword this in a dry formal way, i can submit such a patch?
> > 
> > If not, how do you suggest we move forward here ?
> > We can replace the GA by a system that is not vulnerable
> 
> I ask again, do you have any reason other than an hypothetical scenario to
> think the GA is vulnerable?

Isnt every vulnerability that was reported to us a "hypothetical" scenario ?


> Or can you mention a point during the last five
> years where any such a vulnerability was taken advantage of?

Lets assume we have 2 projects in one the vulnerability was taken advantage of
while in the other it was not.

How would you tell them apart ?

in both these universes 11 people join over the course of a year

In one universe these are all just random new developers. In the other they
are payed to gain vote power and control.

If you list their names from both of these universes, you will notice a
shocking detail
in both universes, its the same people, just in one they where payed and
in the other they joined for their own reasons.

I hope you see that we cannot detect this
Then how would "not detecting" this, mean anything ?

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Nicolas George]

Michael Niedermayer (12025-02-03):
> Lets assume we have 2 projects in one the vulnerability was taken advantage of
> while in the other it was not.
> 
> How would you tell them apart ?

One of them would have a software-defined radio subsystem, the other
not.

Regards,

-- 
  Nicolas George
_______________________________________________
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".