[FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule

[FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Hi,
in the 'avcodec/s302m: enable non-PCM decoding' thread it became
apparent that there is wide disagreement about the interpretation of
this line in the TC rules:

> If the disagreement involves a member of the TC, that member should
> recuse themselves from the decision.

The word 'involves' in it can be intepreted a variety of very different
ways, to apply to TC members who e.g.:
1) authored the changes that are being objected to
2) are objecting to the changes
3) have any opinion on the changes, either positive or negative
4) have previously voiced an opinion that would apply to the changes
5) authored the code that is being modified
6) have a financial or other similar interest in a specific outcome of
   the disagreement

I believe the best way to address this is to make the rule more
explicit, so I propose that people with an opinion on the matter submit
their preferred wording, and then we can have the GA vote on it.

Cheers,
-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

My personal opinion is that broad interpretations of the rule in
question are highly undesirable, as they punish TC members for active
participation in the project. And since TC members tend to be among the
most active contributors, this can substantially reduce our already low
review rate, and lead to other perverse incentives - e.g. TC members
hiding their opinions for fear of losing their vote.

Moreover, I believe that arguments like "people should not sit in
judgement of their own patches" that sound common-sense reasonable on
the surface, are actually based on a misunderstanding of the notion of
conflict of interest and have no real basis.

The mandate of TC members is to use their technical expertise and
opinions to judge what is best for the project. Why should that be in
conflict with a TC member writing a patch - again according to their
judgement of what is best for the project? I believe there is no
conflict here, and thus no reason TC members could not vote on their own
patches, as long as they wrote those patches in accordance with their
mandate.

> The word 'involves' in it can be intepreted a variety of very different
> ways, to apply to TC members who e.g.:
> 1) authored the changes that are being objected to
> 2) are objecting to the changes
> 3) have any opinion on the changes, either positive or negative
> 4) have previously voiced an opinion that would apply to the changes
> 5) authored the code that is being modified
> 6) have a financial or other similar interest in a specific outcome of
>    the disagreement

So IMO the only case that needs to be excluded is 6) - an actual
conflict of interest. I therefore propose the following wording changes:

--- a/doc/community.texi
+++ b/doc/community.texi
-If the disagreement involves a member of the TC, that member should recuse themselves from the decision.

+ Each TC member must vote on such decision according to what is, in their
+ view, best for the project. If a TC member is affected by a conflict of
+ interest with regards to the case, they must announce it and recuse
+ themselves from the TC discussion and vote. A conflict of interest is
+ presumed to occur when a TC member has a personal interest (e.g.
+ financial) in a specific outcome of the case.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Marton Balint]

On Tue, 20 Feb 2024, Anton Khirnov wrote:

> My personal opinion is that broad interpretations of the rule in
> question are highly undesirable, as they punish TC members for active
> participation in the project. And since TC members tend to be among the
> most active contributors, this can substantially reduce our already low
> review rate, and lead to other perverse incentives - e.g. TC members
> hiding their opinions for fear of losing their vote.
>
> Moreover, I believe that arguments like "people should not sit in
> judgement of their own patches" that sound common-sense reasonable on
> the surface, are actually based on a misunderstanding of the notion of
> conflict of interest and have no real basis.
>
> The mandate of TC members is to use their technical expertise and
> opinions to judge what is best for the project. Why should that be in
> conflict with a TC member writing a patch - again according to their
> judgement of what is best for the project? I believe there is no
> conflict here, and thus no reason TC members could not vote on their own
> patches, as long as they wrote those patches in accordance with their
> mandate.
>
>> The word 'involves' in it can be intepreted a variety of very different
>> ways, to apply to TC members who e.g.:
>> 1) authored the changes that are being objected to
>> 2) are objecting to the changes
>> 3) have any opinion on the changes, either positive or negative
>> 4) have previously voiced an opinion that would apply to the changes
>> 5) authored the code that is being modified
>> 6) have a financial or other similar interest in a specific outcome of
>>    the disagreement
>
> So IMO the only case that needs to be excluded is 6) - an actual
> conflict of interest. I therefore propose the following wording changes:

We have no means to prove financial interest, because it is not public. 
For practical reasons, using patch authorship is better. Or maybe a more 
general solution against bias is somewhat increasing the number of people 
in the TC, and removing this rule alltogether.

Regards,
Marton


>
> --- a/doc/community.texi
> +++ b/doc/community.texi
> -If the disagreement involves a member of the TC, that member should recuse themselves from the decision.
>
> + Each TC member must vote on such decision according to what is, in their
> + view, best for the project. If a TC member is affected by a conflict of
> + interest with regards to the case, they must announce it and recuse
> + themselves from the TC discussion and vote. A conflict of interest is
> + presumed to occur when a TC member has a personal interest (e.g.
> + financial) in a specific outcome of the case.
>
> -- 
> Anton Khirnov
> _______________________________________________
> 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Marton Balint (2024-02-20 10:12:34)
> We have no means to prove financial interest, because it is not public. 

We also have no means to prove that committee members are acting in the
project's interest.

E.g. if I had no qualms about being dishonest, I could always ask a
friend to object to controversial patches in my place, so I wouldn't
lose my vote, and nobody could prove it.

In the end some things have to be taken on trust.

> For practical reasons, using patch authorship is better. Or maybe a more 
> general solution against bias is somewhat increasing the number of people 
> in the TC, and removing this rule alltogether.

I woould be concerned about making the TC too slow and unwieldy, it
already takes a lot of effort to push any decisions through. Keep in
mind that during all of its existence it only ever made two decisions,
and one of them spent over a year in limbo.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Marton Balint]

On Tue, 20 Feb 2024, Anton Khirnov wrote:

> Quoting Marton Balint (2024-02-20 10:12:34)
>> We have no means to prove financial interest, because it is not public.
>
> We also have no means to prove that committee members are acting in the
> project's interest.
>
> E.g. if I had no qualms about being dishonest, I could always ask a
> friend to object to controversial patches in my place, so I wouldn't
> lose my vote, and nobody could prove it.
>
> In the end some things have to be taken on trust.

My concern is bad mouthing others based on assumed financial interest and 
endless discussion if that interest is "serious" or not. If your payjob 
uses ffmpeg, or if you ever want money for some ffmpeg related work, that 
is a financial interest right there.

If somebody feels that voting would not be fair, he can always abstain. 
I'd rather keep that fully trust based, to avoid rule interpretation 
wars and discussions about assumed interests.

An interest is not inherently bad, selfish contributions (financial 
reasons or not) is a huge factor in open source.

>
>> For practical reasons, using patch authorship is better. Or maybe a more
>> general solution against bias is somewhat increasing the number of people
>> in the TC, and removing this rule alltogether.
>
> I woould be concerned about making the TC too slow and unwieldy, it
> already takes a lot of effort to push any decisions through. Keep in
> mind that during all of its existence it only ever made two decisions,
> and one of them spent over a year in limbo.

So with 7 people, it would have been two years? :)

Have the TC meet weekly if there is an agenda, and have votes after 
meeting. With more people it is not that big of a deal if somebody 
cannot attend. And have a rule in place to resolve ties. It can be as 
simple as to accept the proposal of the party who raised the issue to the 
TC.

Regards,
Marton
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Marton Balint (2024-02-20 20:32:19)
> 
> 
> On Tue, 20 Feb 2024, Anton Khirnov wrote:
> 
> > Quoting Marton Balint (2024-02-20 10:12:34)
> >> We have no means to prove financial interest, because it is not public.
> >
> > We also have no means to prove that committee members are acting in the
> > project's interest.
> >
> > E.g. if I had no qualms about being dishonest, I could always ask a
> > friend to object to controversial patches in my place, so I wouldn't
> > lose my vote, and nobody could prove it.
> >
> > In the end some things have to be taken on trust.
> 
> My concern is bad mouthing others based on assumed financial interest and 
> endless discussion if that interest is "serious" or not. If your payjob 
> uses ffmpeg, or if you ever want money for some ffmpeg related work, that 
> is a financial interest right there.
> 
> If somebody feels that voting would not be fair, he can always abstain. 
> I'd rather keep that fully trust based, to avoid rule interpretation 
> wars and discussions about assumed interests.
> 
> An interest is not inherently bad, selfish contributions (financial 
> reasons or not) is a huge factor in open source.

I'm deliberately phrasing it as financial interest *in a specific
outcome*, not just being paid to work on the project in general.

Also, in my updated proposal the conflict of interest is self-assessed
by the TC member in question, which I think should address these
concerns.

> >
> >> For practical reasons, using patch authorship is better. Or maybe a more
> >> general solution against bias is somewhat increasing the number of people
> >> in the TC, and removing this rule alltogether.
> >
> > I woould be concerned about making the TC too slow and unwieldy, it
> > already takes a lot of effort to push any decisions through. Keep in
> > mind that during all of its existence it only ever made two decisions,
> > and one of them spent over a year in limbo.
> 
> So with 7 people, it would have been two years? :)
> 
> Have the TC meet weekly if there is an agenda, and have votes after 
> meeting. With more people it is not that big of a deal if somebody 
> cannot attend. And have a rule in place to resolve ties. It can be as 
> simple as to accept the proposal of the party who raised the issue to the 
> TC.

Honestly, implementing this sounds like a significantly bigger project
than I want (or have the resources) to do at this point.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Gyan Doshi]

On 2024-02-20 02:20 pm, Anton Khirnov wrote:
> So IMO the only case that needs to be excluded is 6) - an actual
> conflict of interest. I therefore propose the following wording changes:
>
> --- a/doc/community.texi
> +++ b/doc/community.texi
> -If the disagreement involves a member of the TC, that member should recuse themselves from the decision.
>
> + Each TC member must vote on such decision according to what is, in their
> + view, best for the project. If a TC member is affected by a conflict of
> + interest with regards to the case, they must announce it and recuse
> + themselves from the TC discussion and vote. A conflict of interest is
> + presumed to occur when a TC member has a personal interest (e.g.
> + financial) in a specific outcome of the case.

1) besides financial interest, what are some other types of 'personal 
interest in a specific outcome of the case'?
2) the proposed wording says, 'they must announce it and recuse 
themselves'. That makes it seem that if a member does not self-attest or 
admit to a conflict of interest, then they cannot be stopped from 
voting. To frame it as a question, what are the independent ways ( i.e. 
not including the said member) of making a conflict of interest 
determination?

Regards,
Gyan
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Gyan Doshi (2024-02-20 11:01:15)
> 
> 
> On 2024-02-20 02:20 pm, Anton Khirnov wrote:
> > So IMO the only case that needs to be excluded is 6) - an actual
> > conflict of interest. I therefore propose the following wording changes:
> >
> > --- a/doc/community.texi
> > +++ b/doc/community.texi
> > -If the disagreement involves a member of the TC, that member should recuse themselves from the decision.
> >
> > + Each TC member must vote on such decision according to what is, in their
> > + view, best for the project. If a TC member is affected by a conflict of
> > + interest with regards to the case, they must announce it and recuse
> > + themselves from the TC discussion and vote. A conflict of interest is
> > + presumed to occur when a TC member has a personal interest (e.g.
> > + financial) in a specific outcome of the case.
> 
> 1) besides financial interest, what are some other types of 'personal 
> interest in a specific outcome of the case'?

The intent is cover all cases where a TC member has substantial
motivation that conflicts with choosing what is best for the project.

Besides money, it could be non-monetary compensation (gifts, promotions,
favors, etc.), or maybe your best friend won't speak to your for a week
if you don't vote for their preferred outcome, and so on. I'm sure
someone can think of other examples.

If you think my wording can be improved, feel welcome to suggest changes
to it, or propose an alternative one and the GA will decide.

> 2) the proposed wording says, 'they must announce it and recuse
> themselves'. That makes it seem that if a member does not self-attest
> or admit to a conflict of interest, then they cannot be stopped from
> voting. To frame it as a question, what are the independent ways (
> i.e. not including the said member) of making a conflict of interest
> determination?

My intent is that a TC member affected by a conflict of interest
* must announce it
* cannot vote
These two points hold independently, so if a TC member fails to announce
a conflict of interest that is then discovered later, then their vote is
invalid.

As for determining conflict of interest in case of dishonest TC members,
I don't think there is a general solution for it. But as I said in my
reply to Marton - we already have to assume honesty and good faith on
part of committee members, since a dishonest person could game any
proposed interpretation.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Gyan Doshi]

On 2024-02-20 04:39 pm, Anton Khirnov wrote:
> As for determining conflict of interest in case of dishonest TC 
> members, I don't think there is a general solution for it.

This is not about dishonesty. Imagine a TC member genuinely does not 
self-assess or agree to a conflict of interest, does that
mean they can vote regardless of what the other members think? In other 
words, by whom and how is a claim of conflict adjudicated?

Regards,
Gyan

_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Gyan Doshi (2024-02-22 07:50:36)
> On 2024-02-20 04:39 pm, Anton Khirnov wrote:
> > As for determining conflict of interest in case of dishonest TC 
> > members, I don't think there is a general solution for it.
> 
> This is not about dishonesty. Imagine a TC member genuinely does not 
> self-assess or agree to a conflict of interest, does that
> mean they can vote regardless of what the other members think? In other 
> words, by whom and how is a claim of conflict adjudicated?

In my updated proposal, based on comments by Niklas and Rémi, I'm
leaving it up to the TC member in question, based on the assumption that
TC members are honest.

A "stronger" version could conceivably leave it to CC to decide
ambiguous cases. Feel free to propose such a version if you prefer it.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Nicolas George]

Anton Khirnov (12024-02-22):
> In my updated proposal, based on comments by Niklas and Rémi, I'm
> leaving it up to the TC member in question, based on the assumption that
> TC members are honest.
> 
> A "stronger" version could conceivably leave it to CC to decide
> ambiguous cases. Feel free to propose such a version if you prefer it.

Your version does nothing to address the issue of the current situation,
where the contributor who has to raise an issue in front of the TC does
not trust one member of the TC to be unbiased on this issue.

I therefore maintain my alternate proposition as is.

-- 
  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] [RFC] clarifying the TC conflict of interest rule

[Gyan Doshi]

On 2024-02-23 01:26 pm, Nicolas George wrote:
> Anton Khirnov (12024-02-22):
>> In my updated proposal, based on comments by Niklas and Rémi, I'm
>> leaving it up to the TC member in question, based on the assumption that
>> TC members are honest.
>>
>> A "stronger" version could conceivably leave it to CC to decide
>> ambiguous cases. Feel free to propose such a version if you prefer it.
> Your version does nothing to address the issue of the current situation,
> where the contributor who has to raise an issue in front of the TC does
> not trust one member of the TC to be unbiased on this issue.

Just to be clear, that's not my basis.

I said,

"As a TC member who is part of the disagreement, I believe your 
participation is recused."

based on the existing rule,

"If the disagreement involves a member of the TC, that member should 
recuse themselves from the decision"

Disagreement implies the existence of opposing sides, so discussion 
members from both sides are barred from the TC proceedings.
The wiggle room in interpretation is over whether 'involves' captures 
all participants, including minor ones, or just the principal interlocutors.
Note that the rule says nothing about patch authorship or asymmetry in 
its application.

Anton's original disagreement, as I understand it, is about the 
propriety of the rule i.e. he believes that pre-existing public 
opposition (or agreement) on the issue should not bar a TC member. 
That's a disagreement with the rule, not with its interpretation.

Regards,
Gyan

_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Nicolas George]

Gyan Doshi (12024-02-23):
> Just to be clear, that's not my basis.
> 
> I said,
> 
> "As a TC member who is part of the disagreement, I believe your
> participation is recused."
> 
> based on the existing rule,
> 
> "If the disagreement involves a member of the TC, that member should recuse
> themselves from the decision"
> 
> Disagreement implies the existence of opposing sides, so discussion members
> from both sides are barred from the TC proceedings.
> The wiggle room in interpretation is over whether 'involves' captures all
> participants, including minor ones, or just the principal interlocutors.
> Note that the rule says nothing about patch authorship or asymmetry in its
> application.
> 
> Anton's original disagreement, as I understand it, is about the propriety of
> the rule i.e. he believes that pre-existing public opposition (or agreement)
> on the issue should not bar a TC member. That's a disagreement with the
> rule, not with its interpretation.

I am not sure what you mean exactly, but I suppose that if you mentioned
the rule here and not any other rule, it was because you thought it was
right to apply it, that this rule applied would make the ruling more
just and trustworthy.

My proposal wants to make absolutely clear your concern was valid.

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] [RFC] clarifying the TC conflict of interest rule

[Zhao Zhili]

> 在 2024年2月23日，下午7:26，Gyan Doshi <ffmpeg@gyani.pro> 写道：
> 
> 
> 
>> On 2024-02-23 01:26 pm, Nicolas George wrote:
>> Anton Khirnov (12024-02-22):
>>> In my updated proposal, based on comments by Niklas and Rémi, I'm
>>> leaving it up to the TC member in question, based on the assumption that
>>> TC members are honest.
>>> 
>>> A "stronger" version could conceivably leave it to CC to decide
>>> ambiguous cases. Feel free to propose such a version if you prefer it.
>> Your version does nothing to address the issue of the current situation,
>> where the contributor who has to raise an issue in front of the TC does
>> not trust one member of the TC to be unbiased on this issue.
> 
> Just to be clear, that's not my basis.
> 
> I said,
> 
> "As a TC member who is part of the disagreement, I believe your participation is recused."
> 
> based on the existing rule,
> 
> "If the disagreement involves a member of the TC, that member should recuse themselves from the decision"

I propose a new method that, instead of recuse TC members, let the author take part in the vote, to make it symmetric.

> 
> Disagreement implies the existence of opposing sides, so discussion members from both sides are barred from the TC proceedings.
> The wiggle room in interpretation is over whether 'involves' captures all participants, including minor ones, or just the principal interlocutors.
> Note that the rule says nothing about patch authorship or asymmetry in its application.
> 
> Anton's original disagreement, as I understand it, is about the propriety of the rule i.e. he believes that pre-existing public opposition (or agreement) on the issue should not bar a TC member. That's a disagreement with the rule, not with its interpretation.
> 
> Regards,
> Gyan
> 
> _______________________________________________
> 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 subje

_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Zhao Zhili (2024-02-23 15:52:50)
> 
> > 在 2024年2月23日，下午7:26，Gyan Doshi <ffmpeg@gyani.pro> 写道：
> > 
> > 
> > 
> >> On 2024-02-23 01:26 pm, Nicolas George wrote:
> >> Anton Khirnov (12024-02-22):
> >>> In my updated proposal, based on comments by Niklas and Rémi, I'm
> >>> leaving it up to the TC member in question, based on the assumption that
> >>> TC members are honest.
> >>> 
> >>> A "stronger" version could conceivably leave it to CC to decide
> >>> ambiguous cases. Feel free to propose such a version if you prefer it.
> >> Your version does nothing to address the issue of the current situation,
> >> where the contributor who has to raise an issue in front of the TC does
> >> not trust one member of the TC to be unbiased on this issue.
> > 
> > Just to be clear, that's not my basis.
> > 
> > I said,
> > 
> > "As a TC member who is part of the disagreement, I believe your participation is recused."
> > 
> > based on the existing rule,
> > 
> > "If the disagreement involves a member of the TC, that member should recuse themselves from the decision"
> 
> I propose a new method that, instead of recuse TC members, let the author take part in the vote, to make it symmetric.

What if the TC member is the author?

Also, if you want it to be made a voting option, please formulate it as
actual text that should replace the disputed line in doc/community.texi.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Ronald S. Bultje]

Hi Nicolas

On Fri, Feb 23, 2024 at 2:56 AM Nicolas George <george@nsup.org> wrote:

> Anton Khirnov (12024-02-22):
> > In my updated proposal, based on comments by Niklas and Rémi, I'm
> > leaving it up to the TC member in question, based on the assumption that
> > TC members are honest.
> >
> > A "stronger" version could conceivably leave it to CC to decide
> > ambiguous cases. Feel free to propose such a version if you prefer it.
>
> Your version does nothing to address the issue of the current situation,
> where the contributor who has to raise an issue in front of the TC does
> not trust one member of the TC to be unbiased on this issue.
>
> I therefore maintain my alternate proposition as is.
>

I think you and Anton are trying to fix different issues. I would propose
to run independent votes over Anton's proposal and your proposal, in no
particular order.

For your proposal, if you want the GA to vote on it, would it be possible
to please more specifically define "soon"? Does it mean "ever"? Or within
what time period? Or is the period irrelevant and is the intention of
desiring to work at the company at the point the conflict takes place more
relevant?

Thanks,
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Ronald S. Bultje (2024-02-23 20:36:11)
> Hi Nicolas
> 
> On Fri, Feb 23, 2024 at 2:56 AM Nicolas George <george@nsup.org> wrote:
> 
> > Anton Khirnov (12024-02-22):
> > > In my updated proposal, based on comments by Niklas and Rémi, I'm
> > > leaving it up to the TC member in question, based on the assumption that
> > > TC members are honest.
> > >
> > > A "stronger" version could conceivably leave it to CC to decide
> > > ambiguous cases. Feel free to propose such a version if you prefer it.
> >
> > Your version does nothing to address the issue of the current situation,
> > where the contributor who has to raise an issue in front of the TC does
> > not trust one member of the TC to be unbiased on this issue.
> >
> > I therefore maintain my alternate proposition as is.
> >
> 
> I think you and Anton are trying to fix different issues. I would propose
> to run independent votes over Anton's proposal and your proposal, in no
> particular order.

I would propose people stop proposing fundamental changes to other
people's proposals and propose something of their own instead, if they
care. Otherwise we'll never get anywhere.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Ronald S. Bultje]

Hi,

On Mon, Feb 26, 2024 at 11:34 AM Anton Khirnov <anton@khirnov.net> wrote:

> Quoting Ronald S. Bultje (2024-02-23 20:36:11)
> > Hi Nicolas
> >
> > On Fri, Feb 23, 2024 at 2:56 AM Nicolas George <george@nsup.org> wrote:
> >
> > > Anton Khirnov (12024-02-22):
> > > > In my updated proposal, based on comments by Niklas and Rémi, I'm
> > > > leaving it up to the TC member in question, based on the assumption
> that
> > > > TC members are honest.
> > > >
> > > > A "stronger" version could conceivably leave it to CC to decide
> > > > ambiguous cases. Feel free to propose such a version if you prefer
> it.
> > >
> > > Your version does nothing to address the issue of the current
> situation,
> > > where the contributor who has to raise an issue in front of the TC does
> > > not trust one member of the TC to be unbiased on this issue.
> > >
> > > I therefore maintain my alternate proposition as is.
> > >
> >
> > I think you and Anton are trying to fix different issues. I would propose
> > to run independent votes over Anton's proposal and your proposal, in no
> > particular order.
>
> I would propose people stop proposing fundamental changes to other
> people's proposals and propose something of their own instead, if they
> care. Otherwise we'll never get anywhere.
>

That's essentially what I was suggesting: run a GA vote on your proposed
amendment, and then run a separate GA vote on Nicolas' proposed amendment.

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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Ronald S. Bultje (2024-02-26 19:12:45)
> That's essentially what I was suggesting: run a GA vote on your proposed
> amendment, and then run a separate GA vote on Nicolas' proposed amendment.

They don't seem orthogonal to me though, they both replace the same
disputed line and seem pretty much mutually exclusive.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Ronald S. Bultje]

Hi,

On Mon, Feb 26, 2024 at 2:17 PM Anton Khirnov <anton@khirnov.net> wrote:

> Quoting Ronald S. Bultje (2024-02-26 19:12:45)
> > That's essentially what I was suggesting: run a GA vote on your proposed
> > amendment, and then run a separate GA vote on Nicolas' proposed
> amendment.
>
> They don't seem orthogonal to me though, they both replace the same
> disputed line and seem pretty much mutually exclusive.
>

Yes.

But I don't think we exclude votes based on that criteria.

We both appear to agree Nicolas should not be able to prevent a vote on
your suggestion, but that is also true the other way around.

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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Ronald S. Bultje (2024-02-26 20:48:03)
> Hi,
> 
> On Mon, Feb 26, 2024 at 2:17 PM Anton Khirnov <anton@khirnov.net> wrote:
> 
> > Quoting Ronald S. Bultje (2024-02-26 19:12:45)
> > > That's essentially what I was suggesting: run a GA vote on your proposed
> > > amendment, and then run a separate GA vote on Nicolas' proposed
> > amendment.
> >
> > They don't seem orthogonal to me though, they both replace the same
> > disputed line and seem pretty much mutually exclusive.
> >
> 
> Yes.
> 
> But I don't think we exclude votes based on that criteria.
> 
> We both appear to agree Nicolas should not be able to prevent a vote on
> your suggestion, but that is also true the other way around.

I don't follow, who is preventing what votes?

The idea is to have a vote on what to do with the above line. One option
on the ballot will be replacing it with my suggestion, another with
Nicolas'.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Rémi Denis-Courmont]

Le maanantaina 26. helmikuuta 2024, 21.48.03 EET Ronald S. Bultje a écrit :
> Hi,
> 
> On Mon, Feb 26, 2024 at 2:17 PM Anton Khirnov <anton@khirnov.net> wrote:
> > Quoting Ronald S. Bultje (2024-02-26 19:12:45)
> > 
> > > That's essentially what I was suggesting: run a GA vote on your proposed
> > > amendment, and then run a separate GA vote on Nicolas' proposed
> > > amendment.
> > 
> > They don't seem orthogonal to me though, they both replace the same
> > disputed line and seem pretty much mutually exclusive.
> 
> Yes.
> 
> But I don't think we exclude votes based on that criteria.

Well no. But if Nicolas' proposal consists of replacing "should" with "must", 
then that is not a valid choice. At a minimum, the other part of the sentence 
would have to be reworded for clarity.

For the record, re himself stated that:
1) The maximalist interpretation of "[to] involve" is the correct one.
2) That his interpretation is the only correct one by virtue of being 
maximalist.

But then he also stated that Anton's and my "extreme" interpretations were 
wrong (to put it midly). Admittedly we brougth those forward only for the sake 
of reductio ad absurdum, but the thing is that they are even broader than his 
alleged One True Interpretation, contradicting both arguments that his is 
maximal and that the maximal one is correct.

But if people insist on voting on that, to be clear, it means that nobody on 
the TC ever can make a valid vote since (as pointed out a number of times now) 
expressing an opinion would count as being involved.

> We both appear to agree Nicolas should not be able to prevent a vote on
> your suggestion, but that is also true the other way around.

Why do you think it is better to have two separate votes vs a three-choice 
vote between no changes, Anton's, Nicolas'? Besides, if Anton's change were 
approved, then Nicolas' proposed change would no longer apply as it is, but 
that's really just the flip side of the argument above that it needs to be 
worded better.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/



_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Nicolas George]

Ronald S. Bultje (12024-02-23):
> I think you and Anton are trying to fix different issues.

Indeed. In fact, our proposals are exactly opposite.

Anton's proposal defangs the rule completely, emptying it from all
authority, allowing members of the TC to boss other developers around.

My proposal strengthens the rule, by making it clear recusal is the
expected action when there is the slightest doubt about a bias. It is
the only way to keep members of the TC equal to the other developers.

-- 
  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] [RFC] clarifying the TC conflict of interest rule

[Niklas Haas]

On Tue, 20 Feb 2024 09:50:33 +0100 Anton Khirnov <anton@khirnov.net> wrote:
> + Each TC member must vote on such decision according to what is, in their
> + view, best for the project. If a TC member is affected by a conflict of
> + interest with regards to the case, they must announce it and recuse
> + themselves from the TC discussion and vote. A conflict of interest is
> + presumed to occur when a TC member has a personal interest (e.g.
> + financial) in a specific outcome of the case.

My preferred wording would change "If a TC member is" to "If a TC member
feels they are" and "must" to "should".

I read it as a common sense recommendation, not a legalese text. It is
ultimately up to the individual to judge whether they are acting in good
faith or not.
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Niklas Haas (2024-02-20 21:50:33)
> On Tue, 20 Feb 2024 09:50:33 +0100 Anton Khirnov <anton@khirnov.net> wrote:
> > + Each TC member must vote on such decision according to what is, in their
> > + view, best for the project. If a TC member is affected by a conflict of
> > + interest with regards to the case, they must announce it and recuse
> > + themselves from the TC discussion and vote. A conflict of interest is
> > + presumed to occur when a TC member has a personal interest (e.g.
> > + financial) in a specific outcome of the case.
> 
> My preferred wording would change "If a TC member is" to "If a TC member
> feels they are" and "must" to "should".
> 
> I read it as a common sense recommendation, not a legalese text. It is
> ultimately up to the individual to judge whether they are acting in good
> faith or not.

Okay, that makes sense to me. I am then changing my proposal to:
------------------------------------------------------------------------
Each TC member must vote on such decision according to what is, in their
view, best for the project. If a TC member feels they are affected by a
conflict of interest with regards to the case, they should announce it
and recuse themselves from the TC discussion and vote. A conflict of
interest is presumed to occur when a TC member has a personal interest
(e.g. financial) in a specific outcome of the case.
------------------------------------------------------------------------

If someone wants a "stronger" version of this among the voting options,
feel welcome to propose one.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Thu, Feb 22, 2024 at 10:14:20PM +0100, Anton Khirnov wrote:
> Quoting Niklas Haas (2024-02-20 21:50:33)
> > On Tue, 20 Feb 2024 09:50:33 +0100 Anton Khirnov <anton@khirnov.net> wrote:
> > > + Each TC member must vote on such decision according to what is, in their
> > > + view, best for the project. If a TC member is affected by a conflict of
> > > + interest with regards to the case, they must announce it and recuse
> > > + themselves from the TC discussion and vote. A conflict of interest is
> > > + presumed to occur when a TC member has a personal interest (e.g.
> > > + financial) in a specific outcome of the case.
> > 
> > My preferred wording would change "If a TC member is" to "If a TC member
> > feels they are" and "must" to "should".
> > 
> > I read it as a common sense recommendation, not a legalese text. It is
> > ultimately up to the individual to judge whether they are acting in good
> > faith or not.
> 
> Okay, that makes sense to me. I am then changing my proposal to:
> ------------------------------------------------------------------------
> Each TC member must vote on such decision according to what is, in their
> view, best for the project. If a TC member feels they are affected by a
> conflict of interest with regards to the case, they should announce it
> and recuse themselves from the TC discussion and vote. A conflict of
> interest is presumed to occur when a TC member has a personal interest
> (e.g. financial) in a specific outcome of the case.
> ------------------------------------------------------------------------
> 
> If someone wants a "stronger" version of this among the voting options,
> feel welcome to propose one.

Lets take a look at "the line"

"If the disagreement involves a member of the TC, that member should recuse themselves from the decision."

There are 3 obvious choices here:
1: (unchanged) "If the disagreement involves a member of the TC, that member should recuse themselves from the decision."
2: (must)      "If the disagreement involves a member of the TC, that member must   recuse themselves from the decision."
3: (remove it) ""

Thats what the vote should be about IMO.

Then seperately, theres the question about the (unrelated) text you want to add
That too has 3 choices
1. (unchanged) ""
2. (should)    "conflict of interest ... they should announce it and recuse themselves ..."
3. (must)      "conflict of interest ... they must   announce it and recuse themselves ..."

Thats what a 2nd independant vote should be _IF_ we dont already have
a unanimous agreement about this.

Now honestly why this uses a "should" after apparently
this very dissussion here showed that "should" is interpreted differently
by different people, i dont know.
I mean either we want people to recuse themselves or we dont if specific
circumstances apply. It cannot be in the per persons free choice if they
recuse themselves in a conflict of interrest.
This just makes no sense. ... Ohh i have a financial interrest in the
outcome, i dont have to recuse myself, i only "should" ahh ok ...

The "Each TC member must vote on such decision according to what is, in their view, best for the project."
I suspect you can just propose adding this and without any vote.
There may be unanimous agreement for this

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] [RFC] clarifying the TC conflict of interest rule

[Paul B Mahol]

Send warmly welcomes to old/new tyrants of FFmpeg.
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Hi Michael,
Quoting Michael Niedermayer (2024-02-24 00:27:08)
> On Thu, Feb 22, 2024 at 10:14:20PM +0100, Anton Khirnov wrote:
> > Quoting Niklas Haas (2024-02-20 21:50:33)
> > > On Tue, 20 Feb 2024 09:50:33 +0100 Anton Khirnov <anton@khirnov.net> wrote:
> > > > + Each TC member must vote on such decision according to what is, in their
> > > > + view, best for the project. If a TC member is affected by a conflict of
> > > > + interest with regards to the case, they must announce it and recuse
> > > > + themselves from the TC discussion and vote. A conflict of interest is
> > > > + presumed to occur when a TC member has a personal interest (e.g.
> > > > + financial) in a specific outcome of the case.
> > > 
> > > My preferred wording would change "If a TC member is" to "If a TC member
> > > feels they are" and "must" to "should".
> > > 
> > > I read it as a common sense recommendation, not a legalese text. It is
> > > ultimately up to the individual to judge whether they are acting in good
> > > faith or not.
> > 
> > Okay, that makes sense to me. I am then changing my proposal to:
> > ------------------------------------------------------------------------
> > Each TC member must vote on such decision according to what is, in their
> > view, best for the project. If a TC member feels they are affected by a
> > conflict of interest with regards to the case, they should announce it
> > and recuse themselves from the TC discussion and vote. A conflict of
> > interest is presumed to occur when a TC member has a personal interest
> > (e.g. financial) in a specific outcome of the case.
> > ------------------------------------------------------------------------
> > 
> > If someone wants a "stronger" version of this among the voting options,
> > feel welcome to propose one.
> 
> Lets take a look at "the line"
> 
> "If the disagreement involves a member of the TC, that member should recuse themselves from the decision."
> 
> There are 3 obvious choices here:
> 1: (unchanged) "If the disagreement involves a member of the TC, that member should recuse themselves from the decision."
> 2: (must)      "If the disagreement involves a member of the TC, that member must   recuse themselves from the decision."
> 3: (remove it) ""
> 
> Thats what the vote should be about IMO.
> 
> Then seperately, theres the question about the (unrelated) text you want to add
> That too has 3 choices
> 1. (unchanged) ""
> 2. (should)    "conflict of interest ... they should announce it and recuse themselves ..."
> 3. (must)      "conflict of interest ... they must   announce it and recuse themselves ..."
> 
> Thats what a 2nd independant vote should be _IF_ we dont already have
> a unanimous agreement about this.
> 
> Now honestly why this uses a "should" after apparently
> this very dissussion here showed that "should" is interpreted differently
> by different people, i dont know.
> I mean either we want people to recuse themselves or we dont if specific
> circumstances apply. It cannot be in the per persons free choice if they
> recuse themselves in a conflict of interrest.
> This just makes no sense. ... Ohh i have a financial interrest in the
> outcome, i dont have to recuse myself, i only "should" ahh ok ...
> 
> The "Each TC member must vote on such decision according to what is, in their view, best for the project."
> I suspect you can just propose adding this and without any vote.
> There may be unanimous agreement for this

I don't understand what point you are trying to make.

Do you want to propose another alternative for the vote?

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Mon, Feb 26, 2024 at 05:52:56PM +0100, Anton Khirnov wrote:
> Hi Michael,
> Quoting Michael Niedermayer (2024-02-24 00:27:08)
> > On Thu, Feb 22, 2024 at 10:14:20PM +0100, Anton Khirnov wrote:
> > > Quoting Niklas Haas (2024-02-20 21:50:33)
> > > > On Tue, 20 Feb 2024 09:50:33 +0100 Anton Khirnov <anton@khirnov.net> wrote:
> > > > > + Each TC member must vote on such decision according to what is, in their
> > > > > + view, best for the project. If a TC member is affected by a conflict of
> > > > > + interest with regards to the case, they must announce it and recuse
> > > > > + themselves from the TC discussion and vote. A conflict of interest is
> > > > > + presumed to occur when a TC member has a personal interest (e.g.
> > > > > + financial) in a specific outcome of the case.
> > > > 
> > > > My preferred wording would change "If a TC member is" to "If a TC member
> > > > feels they are" and "must" to "should".
> > > > 
> > > > I read it as a common sense recommendation, not a legalese text. It is
> > > > ultimately up to the individual to judge whether they are acting in good
> > > > faith or not.
> > > 
> > > Okay, that makes sense to me. I am then changing my proposal to:
> > > ------------------------------------------------------------------------
> > > Each TC member must vote on such decision according to what is, in their
> > > view, best for the project. If a TC member feels they are affected by a
> > > conflict of interest with regards to the case, they should announce it
> > > and recuse themselves from the TC discussion and vote. A conflict of
> > > interest is presumed to occur when a TC member has a personal interest
> > > (e.g. financial) in a specific outcome of the case.
> > > ------------------------------------------------------------------------
> > > 
> > > If someone wants a "stronger" version of this among the voting options,
> > > feel welcome to propose one.
> > 
> > Lets take a look at "the line"
> > 
> > "If the disagreement involves a member of the TC, that member should recuse themselves from the decision."
> > 
> > There are 3 obvious choices here:
> > 1: (unchanged) "If the disagreement involves a member of the TC, that member should recuse themselves from the decision."
> > 2: (must)      "If the disagreement involves a member of the TC, that member must   recuse themselves from the decision."
> > 3: (remove it) ""
> > 
> > Thats what the vote should be about IMO.
> > 
> > Then seperately, theres the question about the (unrelated) text you want to add
> > That too has 3 choices
> > 1. (unchanged) ""
> > 2. (should)    "conflict of interest ... they should announce it and recuse themselves ..."
> > 3. (must)      "conflict of interest ... they must   announce it and recuse themselves ..."
> > 
> > Thats what a 2nd independant vote should be _IF_ we dont already have
> > a unanimous agreement about this.
> > 
> > Now honestly why this uses a "should" after apparently
> > this very dissussion here showed that "should" is interpreted differently
> > by different people, i dont know.
> > I mean either we want people to recuse themselves or we dont if specific
> > circumstances apply. It cannot be in the per persons free choice if they
> > recuse themselves in a conflict of interrest.
> > This just makes no sense. ... Ohh i have a financial interrest in the
> > outcome, i dont have to recuse myself, i only "should" ahh ok ...
> > 
> > The "Each TC member must vote on such decision according to what is, in their view, best for the project."
> > I suspect you can just propose adding this and without any vote.
> > There may be unanimous agreement for this
> 
> I don't understand what point you are trying to make.

Look at the 3 patches i just posted.
I suspect we can move alot closer to what you suggest without a vote but
simply by consensus

And then do a vote just on what remains


> 
> Do you want to propose another alternative for the vote?

If theres something remaining that we do not agree on then yes

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-02-26 23:47:20)
> 
> Look at the 3 patches i just posted.
> I suspect we can move alot closer to what you suggest without a vote but
> simply by consensus

Your patches use a 'must' wording, while multiple people would prefer a
'should'.

But even more importantly, you are leaving the disputed line as is, so
it's not solving the problem at all.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Tue, Feb 27, 2024 at 08:20:30AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-26 23:47:20)
> > 
> > Look at the 3 patches i just posted.
> > I suspect we can move alot closer to what you suggest without a vote but
> > simply by consensus
> 
> Your patches use a 'must' wording,

Then please reply to them and explain your point, why the wording
is bad, what alternative wording you suggest and why thats better.
Its a patch, we discuss patches here on ffmpeg-devel


> while multiple people would prefer a
> 'should'.
>

> But even more importantly, you are leaving the disputed line as is, so
> it's not solving the problem at all.

The questions about
1. allowing votes under conflict of interrest
2. if votes must be in the best interrest of the project
3. if one can vote on their own disagreements
...

are 3+ seperate things.

You are trying to pack good changes with a change that allows one to
vote on ones own disagreements.

I think a vote should be about what is disputed.
Not on a bunch of things we all seem to agree about bound to something people
disagree about.

thx

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

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-02-27 17:55:30)
> On Tue, Feb 27, 2024 at 08:20:30AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-02-26 23:47:20)
> > > 
> > > Look at the 3 patches i just posted.
> > > I suspect we can move alot closer to what you suggest without a vote but
> > > simply by consensus
> > 
> > Your patches use a 'must' wording,
> 
> Then please reply to them and explain your point, why the wording
> is bad, what alternative wording you suggest and why thats better.
> Its a patch, we discuss patches here on ffmpeg-devel

Hijacking other people's patches without their consent is what we do NOT
do though.

> > while multiple people would prefer a
> > 'should'.
> >
> 
> > But even more importantly, you are leaving the disputed line as is, so
> > it's not solving the problem at all.
> 
> The questions about
> 1. allowing votes under conflict of interrest
> 2. if votes must be in the best interrest of the project
> 3. if one can vote on their own disagreements
> ...
> 
> are 3+ seperate things.
> 
> You are trying to pack good changes with a change that allows one to
> vote on ones own disagreements.

And you are trying to pass your personal opinions on which changes are
good (and by implication which are not-good) as objective facts. I wish
you'd stop doing that. I presented an argument for why *in my opinion*
there is no problem with TC members voting on their own patches. You are
welcome to disagree, but that is exactly why I am proposing a vote.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
[...]
> their preferred wording, and then we can have the GA vote on it.

Before this GA vote, we need another extra member discussion/vote.
Because the last GA reset droped several developers from the GA

thx

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

Democracy is the form of government in which you can choose your dictator

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Rémi Denis-Courmont]

Le 20 février 2024 16:01:11 GMT+02:00, Michael Niedermayer <michael@niedermayer.cc> a écrit :
>On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
>[...]
>> their preferred wording, and then we can have the GA vote on it.
>
>Before this GA vote, we need another extra member discussion/vote.
>Because the last GA reset droped several developers from the GA

And so what?

Changing the voting body specifically before a decision, and outside the normal flow, sounds like a thinly veiled attempt at altering the ballot results, TBH. It's also unfair to people who contributed code in the past two months and will have to wait until the next normal renewal.

Maybe you mean well, but we can't read your mind, and it *looks* like a bad idea.

-1
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-02-20 15:01:11)
> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
> [...]
> > their preferred wording, and then we can have the GA vote on it.
> 
> Before this GA vote, we need another extra member discussion/vote.
> Because the last GA reset droped several developers from the GA

I see neither why would we "need" such a vote, or why should it be
related to this one.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-20 15:01:11)
> > On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
> > [...]
> > > their preferred wording, and then we can have the GA vote on it.
> > 
> > Before this GA vote, we need another extra member discussion/vote.
> > Because the last GA reset droped several developers from the GA
> 
> I see neither why would we "need" such a vote, or why should it be
> related to this one.

Because thats what was done in the past.
The extra member vote was done between a GA reset and the following votes
like the CC/TC votes
The exception was the STF vote because there just was not enough time

We should do this consistently, and
given that we reset the GA every 6 months, thats the natural rate
at which to do a extra member vote (unless there is no other vote then
the extra member vote can be skiped as it would make no difference)

thx

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

Nations do behave wisely once they have exhausted all other alternatives. 
-- Abba Eban

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Cosmin Stejerean via ffmpeg-devel]

> On Feb 20, 2024, at 12:41 PM, Michael Niedermayer <michael@niedermayer.cc> wrote:
> 
> On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2024-02-20 15:01:11)
>>> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
>>> [...]
>>>> their preferred wording, and then we can have the GA vote on it.
>>> 
>>> Before this GA vote, we need another extra member discussion/vote.
>>> Because the last GA reset droped several developers from the GA
>> 
>> I see neither why would we "need" such a vote, or why should it be
>> related to this one.
> 
> Because thats what was done in the past.
> The extra member vote was done between a GA reset and the following votes
> like the CC/TC votes
> The exception was the STF vote because there just was not enough time
> 
> We should do this consistently, and
> given that we reset the GA every 6 months, thats the natural rate
> at which to do a extra member vote (unless there is no other vote then
> the extra member vote can be skiped as it would make no difference)

It's not clear from https://www.ffmpeg.org/community.html that the extra members should be refreshed every time the GA is updated or that a vote should get held up if that hasn't happened yet. 

> Additional members are added to the General Assembly through a vote after proposal by a member of the General Assembly. They are part of the GA for two years, after which they need a confirmation by the GA.

It looks like a request to add extra members to the GA should be done explicitly by someone requesting a vote on it, which can be done at any time. Waiting until something else comes up for a vote seems suboptimal because it then delays that first decision by at least a couple of weeks (given the rules for voting).

- Cosmin








_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Tue, Feb 20, 2024 at 09:12:11PM +0000, Cosmin Stejerean via ffmpeg-devel wrote:
> 
> 
> > On Feb 20, 2024, at 12:41 PM, Michael Niedermayer <michael@niedermayer.cc> wrote:
> > 
> > On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote:
> >> Quoting Michael Niedermayer (2024-02-20 15:01:11)
> >>> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
> >>> [...]
> >>>> their preferred wording, and then we can have the GA vote on it.
> >>> 
> >>> Before this GA vote, we need another extra member discussion/vote.
> >>> Because the last GA reset droped several developers from the GA
> >> 
> >> I see neither why would we "need" such a vote, or why should it be
> >> related to this one.
> > 
> > Because thats what was done in the past.
> > The extra member vote was done between a GA reset and the following votes
> > like the CC/TC votes
> > The exception was the STF vote because there just was not enough time
> > 
> > We should do this consistently, and
> > given that we reset the GA every 6 months, thats the natural rate
> > at which to do a extra member vote (unless there is no other vote then
> > the extra member vote can be skiped as it would make no difference)
> 
> It's not clear from https://www.ffmpeg.org/community.html that the extra members should be refreshed every time the GA is updated or that a vote should get held up if that hasn't happened yet. 
> 

> > Additional members are added to the General Assembly through a vote after proposal by a member of the General Assembly. They are part of the GA for two years, after which they need a confirmation by the GA.
> 
> It looks like a request to add extra members to the GA should be done explicitly by someone requesting a vote on it, which can be done at any time. Waiting until something else comes up for a vote seems suboptimal because it then delays that first decision by at least a couple of weeks (given the rules for voting).

We probably dont vote every 6 month on anything

If we wait for a vote, and only then do a extra member vote before, that would
result in some delay but fewer votes

Than

if someone starts a extra member vote every 6 month because its unknown if
maybe in the next 6 month there could be a vote

so for me, it seemed natural to only do this when theres some decision
to be made. (which yes, could add some delay)
This is also what we did previously. we only did extra member votes when there
was something to vote on like CC/TC

thx

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

Democracy is the form of government in which you can choose your dictator

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-02-20 22:51:20)
> On Tue, Feb 20, 2024 at 09:12:11PM +0000, Cosmin Stejerean via ffmpeg-devel wrote:
> > 
> > 
> > > On Feb 20, 2024, at 12:41 PM, Michael Niedermayer <michael@niedermayer.cc> wrote:
> > > 
> > > On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote:
> > >> Quoting Michael Niedermayer (2024-02-20 15:01:11)
> > >>> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
> > >>> [...]
> > >>>> their preferred wording, and then we can have the GA vote on it.
> > >>> 
> > >>> Before this GA vote, we need another extra member discussion/vote.
> > >>> Because the last GA reset droped several developers from the GA
> > >> 
> > >> I see neither why would we "need" such a vote, or why should it be
> > >> related to this one.
> > > 
> > > Because thats what was done in the past.
> > > The extra member vote was done between a GA reset and the following votes
> > > like the CC/TC votes
> > > The exception was the STF vote because there just was not enough time
> > > 
> > > We should do this consistently, and
> > > given that we reset the GA every 6 months, thats the natural rate
> > > at which to do a extra member vote (unless there is no other vote then
> > > the extra member vote can be skiped as it would make no difference)
> > 
> > It's not clear from https://www.ffmpeg.org/community.html that the extra members should be refreshed every time the GA is updated or that a vote should get held up if that hasn't happened yet. 
> > 
> 
> > > Additional members are added to the General Assembly through a vote after proposal by a member of the General Assembly. They are part of the GA for two years, after which they need a confirmation by the GA.
> > 
> > It looks like a request to add extra members to the GA should be done explicitly by someone requesting a vote on it, which can be done at any time. Waiting until something else comes up for a vote seems suboptimal because it then delays that first decision by at least a couple of weeks (given the rules for voting).
> 
> We probably dont vote every 6 month on anything
> 
> If we wait for a vote, and only then do a extra member vote before, that would
> result in some delay but fewer votes
> 
> Than
> 
> if someone starts a extra member vote every 6 month because its unknown if
> maybe in the next 6 month there could be a vote
> 
> so for me, it seemed natural to only do this when theres some decision
> to be made. (which yes, could add some delay)
> This is also what we did previously. we only did extra member votes when there
> was something to vote on like CC/TC

No, this is not what happened. We did the extra member votes as a part
of a "grand reset" of the voting system, after it was gridlocked for
years.

I agree with Cosmin that it does not follow that we have to vote for
extra members as a prelude to any other vote.

Moreover, you seem to be arguing yet again that anyone dropped from GA
because of inactivity needs to be added back as an extra member. You've
raised this point before, and GA disagreed, repeatedly. First in 2020
when it was agreed that GA is made up of *active contributors*. Then
again last October, when your proposal to never drop anyone from GA lost
by a large margin to the winning option.

So if you want someone voted in as an extra member, feel free to propose
a vote on them (assuming they consent), but please don't delay unrelated
issues because of that.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Thu, Feb 22, 2024 at 10:54:56PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-20 22:51:20)
> > On Tue, Feb 20, 2024 at 09:12:11PM +0000, Cosmin Stejerean via ffmpeg-devel wrote:
> > > 
> > > 
> > > > On Feb 20, 2024, at 12:41 PM, Michael Niedermayer <michael@niedermayer.cc> wrote:
> > > > 
> > > > On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote:
> > > >> Quoting Michael Niedermayer (2024-02-20 15:01:11)
> > > >>> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
> > > >>> [...]
> > > >>>> their preferred wording, and then we can have the GA vote on it.
> > > >>> 
> > > >>> Before this GA vote, we need another extra member discussion/vote.
> > > >>> Because the last GA reset droped several developers from the GA
> > > >> 
> > > >> I see neither why would we "need" such a vote, or why should it be
> > > >> related to this one.
> > > > 
> > > > Because thats what was done in the past.
> > > > The extra member vote was done between a GA reset and the following votes
> > > > like the CC/TC votes
> > > > The exception was the STF vote because there just was not enough time
> > > > 
> > > > We should do this consistently, and
> > > > given that we reset the GA every 6 months, thats the natural rate
> > > > at which to do a extra member vote (unless there is no other vote then
> > > > the extra member vote can be skiped as it would make no difference)
> > > 
> > > It's not clear from https://www.ffmpeg.org/community.html that the extra members should be refreshed every time the GA is updated or that a vote should get held up if that hasn't happened yet. 
> > > 
> > 
> > > > Additional members are added to the General Assembly through a vote after proposal by a member of the General Assembly. They are part of the GA for two years, after which they need a confirmation by the GA.
> > > 
> > > It looks like a request to add extra members to the GA should be done explicitly by someone requesting a vote on it, which can be done at any time. Waiting until something else comes up for a vote seems suboptimal because it then delays that first decision by at least a couple of weeks (given the rules for voting).
> > 
> > We probably dont vote every 6 month on anything
> > 
> > If we wait for a vote, and only then do a extra member vote before, that would
> > result in some delay but fewer votes
> > 
> > Than
> > 
> > if someone starts a extra member vote every 6 month because its unknown if
> > maybe in the next 6 month there could be a vote
> > 
> > so for me, it seemed natural to only do this when theres some decision
> > to be made. (which yes, could add some delay)
> > This is also what we did previously. we only did extra member votes when there
> > was something to vote on like CC/TC
> 
> No, this is not what happened. We did the extra member votes as a part
> of a "grand reset" of the voting system, after it was gridlocked for
> years.
> 
> I agree with Cosmin that it does not follow that we have to vote for
> extra members as a prelude to any other vote.

If you want everyone to accept the vote as valid you should make sure
noone is left out.


> 
> Moreover, you seem to be arguing yet again that anyone dropped from GA
> because of inactivity needs to be added back as an extra member. You've

The beauty of politics, whatever one says, others will present it in a
way that makes it look bad.

IIRC two people where droped, carl and andriy.
andriy is maintaining patchwork and also IIRC helped setup the vote docker
thingy. He isnt in the GA because the GA counts people based on authored commits
but none the less he had enough commits previously so he wasnt in the extra member
vote. He just fell below the threshold.


> raised this point before, and GA disagreed, repeatedly. First in 2020
> when it was agreed that GA is made up of *active contributors*. Then
> again last October, when your proposal to never drop anyone from GA lost
> by a large margin to the winning option.

"your proposal"? ok :)

I think the idea was to provide voters with all options that would represent
everyones position fairly ane then find out what was what people as majority
where happiest with. Not so much my vs your, but whatever


thx

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Nicolas George]

Anton Khirnov (12024-02-20):
> Hi,
> in the 'avcodec/s302m: enable non-PCM decoding' thread it became
> apparent that there is wide disagreement about the interpretation of
> this line in the TC rules:
> 
> > If the disagreement involves a member of the TC, that member should
> > recuse themselves from the decision.
> 
> The word 'involves' in it can be intepreted a variety of very different
> ways, to apply to TC members who e.g.:
> 1) authored the changes that are being objected to
> 2) are objecting to the changes
> 3) have any opinion on the changes, either positive or negative
> 4) have previously voiced an opinion that would apply to the changes
> 5) authored the code that is being modified
> 6) have a financial or other similar interest in a specific outcome of
>    the disagreement
> 
> I believe the best way to address this is to make the rule more
> explicit, so I propose that people with an opinion on the matter submit
> their preferred wording, and then we can have the GA vote on it.

Considering that the role of the TC, like any body of this kind, is not
only to *decide* but to *convince* the involved parties that the
decision is *fair*,

Considering that to achieve that goal, the rules must not only exclude
real conflicts of interest but even the appearance of bias,

Considering that sitting on the TC is not a *right*, does not mean the
member is *above* the other developers, but rather a *duty*,

Considering that the TC has several members who take up the duty if one
or more members are recused or recuse themselves,

Considering that therefore it is best for the trust in the system to
exclude preventively all members of the TC who might exhibit a bias or
the suspicion of a bias to let decide the members who clearly had no
pre-conception on the issue,

I propose the very extensive rule that follows:

Any member of the TC who had a strong opinion on the question raised
before it was raised should recuse themselves.

In particular, must recuse themselves any member of the TC who:
- participated in the discussion (on the ML, on IRC or elsewhere) in a
  specific direction (minor comments and questions being acceptable);
- has a personal interest in the outcome;
- is, was recently or soon will be employed by an entity having a
  personal interest in the outcome or has any kind of hierarchical
  relationship with such entity.
Failure to do so would result, upon discovery, into the exclusion of all
FFmpeg governance bodies, including the general assembly, for a duration
of no less than five years.

Additionally, any member of the general assembly can recuse any member
of the TC without having to provide a reason.

If the application of these rules result in all members of the TC
recused or if the remaining members do not feel comfortable being too
few, that means the project is in a crisis of trust that needs to be
resolved by the general assembly.

-- 
  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] [RFC] clarifying the TC conflict of interest rule

[Rémi Denis-Courmont]

Le tiistaina 20. helmikuuta 2024, 10.22.57 EET Anton Khirnov a écrit :
> Hi,
> in the 'avcodec/s302m: enable non-PCM decoding' thread it became
> apparent that there is wide disagreement about the interpretation of
> 
> this line in the TC rules:
> > If the disagreement involves a member of the TC, that member should
> > recuse themselves from the decision.
> 
> The word 'involves' in it can be intepreted a variety of very different
> ways, to apply to TC members who e.g.:
> 1) authored the changes that are being objected to
> 2) are objecting to the changes
> 3) have any opinion on the changes, either positive or negative
> 4) have previously voiced an opinion that would apply to the changes
> 5) authored the code that is being modified
> 6) have a financial or other similar interest in a specific outcome of
>    the disagreement
> 
> I believe the best way to address this is to make the rule more
> explicit,

The sentence in question can hardly be called a "rule". It is a 
recommendation. Maybe the author did not mean it that way, but what matters is 
the text that people agreed upon, not a post-facto originalist interpretation.

> so I propose that people with an opinion on the matter submit
> their preferred wording, and then we can have the GA vote on it.

It is completely normal, and even expected, of TC members to have opinions. 
The TC is a, well, Technical commitee, not a court room. The TC is making 
technical assessment, not determining guilt and giving sentences.

Of course, in principles we want to avoid biases of non-technical nature, 
including but not limited to financial or material conflict of interests. But I 
fail to see how such a constraint can be enforced in practice, and it is not 
even really a clear-cut and objective constraint either.

Furthermore, I don't think that a vote could *practically* be deemd invalid 
after the fact. I mean, One Does Not Simply revert the code that was merged as 
a consequence of a TC decision.

I however think that technical biases are totally acceptable, and even 
expected. Afterall, I certainly expect TC member to more or less agree with 
the subjective technical leanings of FFmpeg, as well as its "open-source 
political" leanings so to say. For example, FFmpeg favours C over C++, and 
outline SIMD assembler over intrinsics, and of course LGPLv2.1 over other 
licences.

All in all, I more or less agree with option 6, but that's assuming that the 
text retains the "should" modal. I don't think we can make a hard "must" rule 
here. In the end, if we are worried about conflict of interests, the most 
effective way around them is to keep diverse membership in the TC to counter-
balance conflicted members.

-- 
Rémi Denis-Courmont
http://www.remlab.net/



_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Rémi Denis-Courmont (2024-02-20 20:57:37)
> Le tiistaina 20. helmikuuta 2024, 10.22.57 EET Anton Khirnov a écrit :
> > Hi,
> > in the 'avcodec/s302m: enable non-PCM decoding' thread it became
> > apparent that there is wide disagreement about the interpretation of
> > 
> > this line in the TC rules:
> > > If the disagreement involves a member of the TC, that member should
> > > recuse themselves from the decision.
> > 
> > The word 'involves' in it can be intepreted a variety of very different
> > ways, to apply to TC members who e.g.:
> > 1) authored the changes that are being objected to
> > 2) are objecting to the changes
> > 3) have any opinion on the changes, either positive or negative
> > 4) have previously voiced an opinion that would apply to the changes
> > 5) authored the code that is being modified
> > 6) have a financial or other similar interest in a specific outcome of
> >    the disagreement
> > 
> > I believe the best way to address this is to make the rule more
> > explicit,
> 
> The sentence in question can hardly be called a "rule". It is a 
> recommendation. Maybe the author did not mean it that way, but what matters is 
> the text that people agreed upon, not a post-facto originalist interpretation.
> 
> > so I propose that people with an opinion on the matter submit
> > their preferred wording, and then we can have the GA vote on it.
> 
> It is completely normal, and even expected, of TC members to have opinions. 
> The TC is a, well, Technical commitee, not a court room. The TC is making 
> technical assessment, not determining guilt and giving sentences.
> 
> Of course, in principles we want to avoid biases of non-technical nature, 
> including but not limited to financial or material conflict of interests. But I 
> fail to see how such a constraint can be enforced in practice, and it is not 
> even really a clear-cut and objective constraint either.
> 
> Furthermore, I don't think that a vote could *practically* be deemd invalid 
> after the fact. I mean, One Does Not Simply revert the code that was merged as 
> a consequence of a TC decision.
> 
> I however think that technical biases are totally acceptable, and even 
> expected. Afterall, I certainly expect TC member to more or less agree with 
> the subjective technical leanings of FFmpeg, as well as its "open-source 
> political" leanings so to say. For example, FFmpeg favours C over C++, and 
> outline SIMD assembler over intrinsics, and of course LGPLv2.1 over other 
> licences.
> 
> All in all, I more or less agree with option 6, but that's assuming that the 
> text retains the "should" modal. I don't think we can make a hard "must" rule 
> here. In the end, if we are worried about conflict of interests, the most 
> effective way around them is to keep diverse membership in the TC to counter-
> balance conflicted members.

I changed my proposal to reflect the points raised by Niklas, which seem
to be mostly equivalent to yours.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
> Hi,
> in the 'avcodec/s302m: enable non-PCM decoding' thread it became
> apparent that there is wide disagreement about the interpretation of
> this line in the TC rules:
> 
> > If the disagreement involves a member of the TC, that member should
> > recuse themselves from the decision.
> 
> The word 'involves' in it can be intepreted a variety of very different
> ways, to apply to TC members who e.g.:
> 1) authored the changes that are being objected to
> 2) are objecting to the changes
> 3) have any opinion on the changes, either positive or negative
> 4) have previously voiced an opinion that would apply to the changes
> 5) authored the code that is being modified
> 6) have a financial or other similar interest in a specific outcome of
>    the disagreement
> 
> I believe the best way to address this is to make the rule more
> explicit, so I propose that people with an opinion on the matter submit
> their preferred wording, and then we can have the GA vote on it.

For the actual vote about changing the rules and the discussion of it.
Each option should provide a patch.
Otherwise you could have a whole new discussion after the vote how
to turn it into a change to the rules

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] [RFC] clarifying the TC conflict of interest rule

[Nicolas George]

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]

Michael Niedermayer (12024-02-23):
> Each option should provide a patch.

Fine. But the wording can be discussed too.

Regards,

-- 
  Nicolas George

[-- Attachment #2: 0001-doc-community-strengthen-TC-member-recusal-rule.patch --]
[-- Type: text/x-diff, Size: 2692 bytes --]

From 7955ed2c1074f85f0f55a58072a8623c8ff4bf34 Mon Sep 17 00:00:00 2001
From: Nicolas George <george@nsup.org>
Date: Fri, 23 Feb 2024 15:12:51 +0100
Subject: [PATCH] doc/community: strengthen TC member recusal rule

The role of the TC, like any body of this kind, is not only to *decide*
but to *convince* the involved parties that the decision is *fair*.

To achieve that goal, the rules must not only exclude real conflicts of
interest but even the appearance of bias.

Sitting on the TC is not a *right*, does not mean the member is *above*
the other developers, but rather a *duty*.

The TC has several members who take up the duty if one or more members
are recused or recuse themselves.

Therefore it is best for the trust in the system to exclude preventively
all members of the TC who might exhibit a bias or the suspicion of a
bias to let decide the members who clearly had no pre-conception on the
issue,

Signed-off-by: Nicolas George <george@nsup.org>
---
 doc/community.texi | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/doc/community.texi b/doc/community.texi
index 90d2b6f366..31d3e21df6 100644
--- a/doc/community.texi
+++ b/doc/community.texi
@@ -82,7 +82,17 @@ The TC has 2 modes of operation: a RFC one and an internal one.
 
 If the TC thinks it needs the input from the larger community, the TC can call for a RFC. Else, it can decide by itself.
 
-If the disagreement involves a member of the TC, that member should recuse themselves from the decision.
+Any member of the TC who had a strong opinion on the question raised before it was raised should recuse themselves.
+
+In particular, must recuse themselves any member of the TC who:
+- participated in the discussion (on the ML, on IRC or elsewhere) in a specific direction (minor comments and questions being acceptable);
+- has a personal interest in the outcome;
+- is, was recently or soon will be employed by an entity having a personal interest in the outcome or has any kind of hierarchical relationship with such entity.
+Failure to do so would result, upon discovery, into the exclusion of all FFmpeg governance bodies, including the general assembly, for a duration of no less than five years.
+
+Additionally, any member of the general assembly can recuse any member of the TC without having to provide a reason.
+
+If the application of these rules result in all members of the TC recused or if the remaining members do not feel comfortable being too few, that means the project is in a crisis of trust that needs to be resolved by the general assembly.
 
 The decision to use a RFC process or an internal discussion is a discretionary decision of the TC.
 
-- 
2.43.0


[-- Attachment #3: 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-02-23 15:00:24)
> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
> > Hi,
> > in the 'avcodec/s302m: enable non-PCM decoding' thread it became
> > apparent that there is wide disagreement about the interpretation of
> > this line in the TC rules:
> > 
> > > If the disagreement involves a member of the TC, that member should
> > > recuse themselves from the decision.
> > 
> > The word 'involves' in it can be intepreted a variety of very different
> > ways, to apply to TC members who e.g.:
> > 1) authored the changes that are being objected to
> > 2) are objecting to the changes
> > 3) have any opinion on the changes, either positive or negative
> > 4) have previously voiced an opinion that would apply to the changes
> > 5) authored the code that is being modified
> > 6) have a financial or other similar interest in a specific outcome of
> >    the disagreement
> > 
> > I believe the best way to address this is to make the rule more
> > explicit, so I propose that people with an opinion on the matter submit
> > their preferred wording, and then we can have the GA vote on it.
> 
> For the actual vote about changing the rules and the discussion of it.
> Each option should provide a patch.
> Otherwise you could have a whole new discussion after the vote how
> to turn it into a change to the rules

My proposal is an excerpt from a patch, just trimmed down to make it
easier to read.

And I don't see what could be ambiguous about it, you just remove one
specific line and replace it with other text as proposed.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Hi all,
it seems the discussion died down, so I intend to start the vote on
Monday (2024-03-04).

The vote description will be as follows:

  There is disagreement about the appropriateness and interpretation of
  the following sentence in Technical Committee rules
  (doc/community.texi):

    > If the disagreement involves a member of the TC, that member
    > should recuse themselves from the decision.

  (see thread starting from [1] for more details)

  How should this sentence be changed? Rank the options below in your
  order of preference.

  [1] https://lists.ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321792.html
      Message-Id <170841737762.27417.14992162535824834057@lain.khirnov.net>

The options I see proposed so far are:

* <left as is>

* <removed without replacement>

* Each TC member must vote on such decision according to what is, in
  their view, best for the project. If a TC member feels they are
  affected by a conflict of interest with regards to the case, they
  should announce it and recuse themselves from the TC discussion and
  vote. A conflict of interest is presumed to occur when a TC member has
  a personal interest (e.g. financial) in a specific outcome of the
  case.

* Any member of the TC who had a strong opinion on the question raised
  before it was raised should recuse themselves.

  In particular, must recuse themselves any member of the TC who:
  - participated in the discussion (on the ML, on IRC or elsewhere) in a
    specific direction (minor comments and questions being acceptable);
  - has a personal interest in the outcome;
  - is, was recently or soon will be employed by an entity having a
    personal interest in the outcome or has any kind of hierarchical
    relationship with such entity.
  Failure to do so would result, upon discovery, into the exclusion of
  all FFmpeg governance bodies, including the general assembly, for a
  duration of no less than five years.

  Additionally, any member of the general assembly can recuse any member
  of the TC without having to provide a reason.

  If the application of these rules result in all members of the TC
  recused or if the remaining members do not feel comfortable being too
  few, that means the project is in a crisis of trust that needs to be
  resolved by the general assembly.

If you wish to propose another option (or I missed one in this thread),
please let me know ASAP.

Cheers,
-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Gyan Doshi]

On 2024-03-01 11:03 pm, Anton Khirnov wrote:
> * Any member of the TC who had a strong opinion on the question raised
>    before it was raised should recuse themselves.
>
>    In particular, must recuse themselves any member of the TC who:
>    - participated in the discussion (on the ML, on IRC or elsewhere) in a
>      specific direction (minor comments and questions being acceptable);
>    - has a personal interest in the outcome;
>    - is, was recently or soon will be employed by an entity having a
>      personal interest in the outcome or has any kind of hierarchical
>      relationship with such entity.
>    Failure to do so would result, upon discovery, into the exclusion of
>    all FFmpeg governance bodies, including the general assembly, for a
>    duration of no less than five years.
>
>    Additionally, any member of the general assembly can recuse any member
>    of the TC without having to provide a reason.

I propose a narrower version for this last point as currently it has a 
mix of unenforceable, broad and harsh elements.

--------
* Any member of the TC who has

   - had a major participation in the discussion or demonstrated a partisan
     disposition on the concerned issue at any public venue, or
   - a financial interest in the outcome, either directly or via current or
     anticipated employment or consideration

   is subject to recusal from participation in the TC activities related 
to the
   issue under consideration. This recusal may be effected either 
directly by
   the TC member, or by a vote of the Community Committee (CC) - the TC 
member
   must not participate in any such vote.

   Failure by the TC member to reveal any such involvement as described 
above,
   if judged intentional and material by the CC, shall result in 
exclusion of
   said member from all FFmpeg governance bodies for a period of no less 
than
   two years.
--------

Regards,
Gyan

_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Ronald S. Bultje]

Hi,

On Sat, Mar 2, 2024 at 12:37 AM Gyan Doshi <ffmpeg@gyani.pro> wrote:

> [..]
>
  This recusal may be effected either directly by
>    the TC member, or by a vote of the Community Committee (CC)
>

The CC is for enforcement of behavioural guidelines (CoC), not for
technical matters, so this strikes me as a bit of a stretch of the CC
mandate.

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] [RFC] clarifying the TC conflict of interest rule

[Cosmin Stejerean via ffmpeg-devel]

> On Mar 2, 2024, at 11:01 AM, Ronald S. Bultje <rsbultje@gmail.com> wrote:
> 
> This recusal may be effected either directly by
>>   the TC member, or by a vote of the Community Committee (CC)
>> 
> 
> The CC is for enforcement of behavioural guidelines (CoC), not for
> technical matters, so this strikes me as a bit of a stretch of the CC
> mandate.

I don't think in this case the CC would be enforcing a technical matter, but rather enforcing the recusal in the case of a conflict of interest when the TC member in question fails to recuse themselves. This does seem appropriate for the CC as the question is one of behavior rather than technical merit.

- Cosmin
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Sat, Mar 02, 2024 at 11:07:40AM +0530, Gyan Doshi wrote:
> 
> 
> On 2024-03-01 11:03 pm, Anton Khirnov wrote:
> > * Any member of the TC who had a strong opinion on the question raised
> >    before it was raised should recuse themselves.
> > 
> >    In particular, must recuse themselves any member of the TC who:
> >    - participated in the discussion (on the ML, on IRC or elsewhere) in a
> >      specific direction (minor comments and questions being acceptable);
> >    - has a personal interest in the outcome;
> >    - is, was recently or soon will be employed by an entity having a
> >      personal interest in the outcome or has any kind of hierarchical
> >      relationship with such entity.
> >    Failure to do so would result, upon discovery, into the exclusion of
> >    all FFmpeg governance bodies, including the general assembly, for a
> >    duration of no less than five years.
> > 
> >    Additionally, any member of the general assembly can recuse any member
> >    of the TC without having to provide a reason.
> 
> I propose a narrower version for this last point as currently it has a mix
> of unenforceable, broad and harsh elements.
> 
> --------
> * Any member of the TC who has
> 
>   - had a major participation in the discussion or demonstrated a partisan
>     disposition on the concerned issue at any public venue, or
>   - a financial interest in the outcome, either directly or via current or
>     anticipated employment or consideration
> 
>   is subject to recusal from participation in the TC activities related to
> the
>   issue under consideration. This recusal may be effected either directly by
>   the TC member, or by a vote of the Community Committee (CC) - the TC
> member
>   must not participate in any such vote.
> 
>   Failure by the TC member to reveal any such involvement as described
> above,
>   if judged intentional and material by the CC, shall result in exclusion of
>   said member from all FFmpeg governance bodies for a period of no less than
>   two years.
> --------

Please provide this as a patch so potential voters can see exactly what before
and after text there is

thx

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Gyan Doshi]

On 2024-03-03 07:04 am, Michael Niedermayer wrote:
> On Sat, Mar 02, 2024 at 11:07:40AM +0530, Gyan Doshi wrote:
>>
>> On 2024-03-01 11:03 pm, Anton Khirnov wrote:
>>> * Any member of the TC who had a strong opinion on the question raised
>>>     before it was raised should recuse themselves.
>>>
>>>     In particular, must recuse themselves any member of the TC who:
>>>     - participated in the discussion (on the ML, on IRC or elsewhere) in a
>>>       specific direction (minor comments and questions being acceptable);
>>>     - has a personal interest in the outcome;
>>>     - is, was recently or soon will be employed by an entity having a
>>>       personal interest in the outcome or has any kind of hierarchical
>>>       relationship with such entity.
>>>     Failure to do so would result, upon discovery, into the exclusion of
>>>     all FFmpeg governance bodies, including the general assembly, for a
>>>     duration of no less than five years.
>>>
>>>     Additionally, any member of the general assembly can recuse any member
>>>     of the TC without having to provide a reason.
>> I propose a narrower version for this last point as currently it has a mix
>> of unenforceable, broad and harsh elements.
>>
>> --------
>> * Any member of the TC who has
>>
>>    - had a major participation in the discussion or demonstrated a partisan
>>      disposition on the concerned issue at any public venue, or
>>    - a financial interest in the outcome, either directly or via current or
>>      anticipated employment or consideration
>>
>>    is subject to recusal from participation in the TC activities related to
>> the
>>    issue under consideration. This recusal may be effected either directly by
>>    the TC member, or by a vote of the Community Committee (CC) - the TC
>> member
>>    must not participate in any such vote.
>>
>>    Failure by the TC member to reveal any such involvement as described
>> above,
>>    if judged intentional and material by the CC, shall result in exclusion of
>>    said member from all FFmpeg governance bodies for a period of no less than
>>    two years.
>> --------
> Please provide this as a patch so potential voters can see exactly what before
> and after text there is

Sent as 'doc/community: rule to avoid conflict of interest and prejudice 
in TC'.

Regards,
Gyan

_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

Hi

On Fri, Mar 01, 2024 at 06:33:12PM +0100, Anton Khirnov wrote:
> Hi all,
> it seems the discussion died down,

There are patches pending, which i will apply soon if no objections
have been raised.

And noone owns law texts. Everyone can propose any derivation
of anothers suggestion. Thats the idea behind evolution and improvment
and the idea behind finding and dicussing variations.

Depending on these patches outcome, i may propose options here

That certainly does not qualify as "discussion died down"

But as a precaution for the strange style of "quick vote before we
find a consensus"

Please add the vote options: (I belive this gives the people a more
complete set of choices)

* Wait for the discussion, consensus and patch based process to finish.
  After which, if disagreements remain, use the GA vote process.

* Add a conflict of interrest text as specified by the patch below

* Replace "If the disagreement involves a member of the TC, that member should recuse themselves from the decision."
  by the conflict of interrest text as specified by the patch below

* Replace "If the disagreement involves a member of the TC, that member should recuse themselves from the decision." by
          "If the disagreement involves a member of the TC, that member must recuse themselves from the decision."
  and add the conflict of interrest text as specified by the patch below

* Replace "If the disagreement involves a member of the TC, that member should recuse themselves from the decision." by
          "If the disagreement involves a member of the TC, that member must recuse themselves from the decision."

(if the patch doesnt apply use best effort to merge manually)
--- a/doc/community.texi
+++ b/doc/community.texi
@@ -82,6 +82,14 @@ The TC has 2 modes of operation: a RFC one and an internal one.

 If the TC thinks it needs the input from the larger community, the TC can call for a RFC. Else, it can decide by itself.

+Each TC member must vote on such decision according to what is, in their view, best for the project.
+
+If a TC member is aware of a conflict of interest with regards to the case, they must announce it
+and recuse themselves from the TC discussion and vote.
+
+A conflict of interest is presumed to occur when a TC member has a personal interest
+(e.g. financial) in a specific outcome of the case that differs from what is best for the project.
+
 If the disagreement involves a member of the TC, that member should recuse themselves from the decision.

 The decision to use a RFC process or an internal discussion is a discretionary decision of the TC.


As you can see we have so many options to consider, its better if we first
go through normal discussions and consensus finding instead of initiating a vote
while patches are pending on the very text the vote is about

thx

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-03-03 03:49:33)
> Hi
> 
> On Fri, Mar 01, 2024 at 06:33:12PM +0100, Anton Khirnov wrote:
> > Hi all,
> > it seems the discussion died down,
> 
> There are patches pending, which i will apply soon if no objections
> have been raised.

I object to these patches. This way of hijacking discussion is just
rude.

> And noone owns law texts.

These patches are not law texts, they are documentation. Authorship and
copyright apply to them, same as to code.

> Everyone can propose any derivation
> of anothers suggestion. Thats the idea behind evolution and improvment
> and the idea behind finding and dicussing variations.

But the problem is not about ownership, but rather about telling people
"stop discussing here and instead go to some other thread and comment on
those other patches".

There seems to be a wide consensus that we have a fundamental
disagreement here and the best way to resolve it is through a vote. It
also seems to me that you keep trying to derail the vote, for unclear
reasons.

> Please add the vote options: (I belive this gives the people a more
> complete set of choices)

Why do you feel you need to bestow all these options upon "the people"?
If "the people" wanted these options, they would have asked for them.
Again, it seems like you are trying to derail the vote.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Sun, Mar 03, 2024 at 10:57:43PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-03-03 03:49:33)
> > Hi
> > 
> > On Fri, Mar 01, 2024 at 06:33:12PM +0100, Anton Khirnov wrote:
> > > Hi all,
> > > it seems the discussion died down,
> > 
> > There are patches pending, which i will apply soon if no objections
> > have been raised.
> 
> I object to these patches. This way of hijacking discussion is just
> rude.
> 
> > And noone owns law texts.
> 
> These patches are not law texts, they are documentation. Authorship and
> copyright apply to them, same as to code.
> 
> > Everyone can propose any derivation
> > of anothers suggestion. Thats the idea behind evolution and improvment
> > and the idea behind finding and dicussing variations.
> 
> But the problem is not about ownership, but rather about telling people
> "stop discussing here and instead go to some other thread and comment on
> those other patches".
> 
> There seems to be a wide consensus that we have a fundamental
> disagreement here and the best way to resolve it is through a vote. It
> also seems to me that you keep trying to derail the vote, for unclear
> reasons.

The vote started as you want TC members (like yourself) to be able to
vote on their own disagreements.
I think thats not a good idea, thats where we dissagree.

But instead of asking this in a vote (which you could have done)
you pair it with the addition of good changes
and then when i want to add these changes you call it "hijacking discussion", "rude."
and "copyright apply to them"
and litterally object to your own change. So it can stay paired in the vote
with the change you want.

Again the changes you want to add / that are in the patches i did send
should be discussed and applied through consensus, iam sure there is wide
consensus to add them in some form.

OTOH I do not know how many people want TC members to be able to vote on
their own disagreements. Some people do want this yes, some people do not
want this.


>
> > Please add the vote options: (I belive this gives the people a more
> > complete set of choices)
>
> Why do you feel you need to bestow all these options upon "the people"?

The point of a vote is to find out what the people want.
The word democracy means
government by the people. especially : rule of the majority. : a government
in which the supreme power is vested in the people and exercised by them

For this they need to have the choice.

Normally we discuss disagreements, try to find consensus and move that way
but here you disregard this and try to push forward with a vote while
blocking your exact own text in one of the 3 patches that your vote
would add.

I hope very much that people even if they agree with the change vote
against it because what you do here is not how democracy should work.
And i dont think the future will be pretty if this style is accepted.
Expect everyone to do this with many changes YOU do not want in.

items should not be paired to get disputed things through. The Community
should be able to decide on the items independantly of each other


> If "the people" wanted these options, they would have asked for them.
> Again, it seems like you are trying to derail the vote.

If you pair things in a vote that others disagree you will have to
accept that some unpaired choices will appear too

thx

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Mon, Mar 04, 2024 at 12:36:21AM +0100, Michael Niedermayer wrote:
> On Sun, Mar 03, 2024 at 10:57:43PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-03-03 03:49:33)
[...]
> >
> > > Please add the vote options: (I belive this gives the people a more
> > > complete set of choices)
> >
> > Why do you feel you need to bestow all these options upon "the people"?
> 
> The point of a vote is to find out what the people want.
> The word democracy means
> government by the people. especially : rule of the majority. : a government
> in which the supreme power is vested in the people and exercised by them
> 
> For this they need to have the choice.
> 
> Normally we discuss disagreements, try to find consensus and move that way
> but here you disregard this and try to push forward with a vote while
> blocking your exact own text in one of the 3 patches that your vote
> would add.
> 

> I hope very much that people even if they agree with the change vote
> against it because what you do here is not how democracy should work.

I didnt word this well.
what i meant is people should vote in favor of the option
they favor (no matter what that is)

But if they are presented with a vote that tries to take away their choice
to funnel them into some other option, they should not accept this.

Alot of real world politics do exactly that
have many unrelated things stuffed in a law that then can only all be
passed or rejected together.
This shouldnt be that way in real world politcs and it also shouldnt be
done in FOSS.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Niklas Haas]

On Mon, 04 Mar 2024 00:56:02 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote:
> On Mon, Mar 04, 2024 at 12:36:21AM +0100, Michael Niedermayer wrote:
> > On Sun, Mar 03, 2024 at 10:57:43PM +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2024-03-03 03:49:33)
> [...]
> > >
> > > > Please add the vote options: (I belive this gives the people a more
> > > > complete set of choices)
> > >
> > > Why do you feel you need to bestow all these options upon "the people"?
> > 
> > The point of a vote is to find out what the people want.
> > The word democracy means
> > government by the people. especially : rule of the majority. : a government
> > in which the supreme power is vested in the people and exercised by them
> > 
> > For this they need to have the choice.
> > 
> > Normally we discuss disagreements, try to find consensus and move that way
> > but here you disregard this and try to push forward with a vote while
> > blocking your exact own text in one of the 3 patches that your vote
> > would add.
> > 
> 
> > I hope very much that people even if they agree with the change vote
> > against it because what you do here is not how democracy should work.
> 
> I didnt word this well.
> what i meant is people should vote in favor of the option
> they favor (no matter what that is)
> 
> But if they are presented with a vote that tries to take away their choice
> to funnel them into some other option, they should not accept this.

I think there was by now sufficient time for everybody with a dissenting
opinion to voice it.

As such, +1 to moving on with voting.
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Nicolas George]

Michael Niedermayer (12024-03-04):
> But if they are presented with a vote that tries to take away their choice
> to funnel them into some other option, they should not accept this.

A good point to note that the vote should obviously not be organized by
somebody who has proposed and defended one of the options.

But at this point, what's a little more of it…

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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-03-04 00:36:21)
> [words words]

Again - why do you personally need so many choices? Just one should be
enough. If someone else wants some other choice on the ballot, they
should ask for it.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Mon, Mar 04, 2024 at 10:15:31PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-03-04 00:36:21)
> > [words words]
> 
> Again - why do you personally need so many choices? Just one should be
> enough. If someone else wants some other choice on the ballot, they
> should ask for it.

Many people do not speak up,
Also there has not been a real discussion from which i can see what the
community prefers.
I asked you to comment on the patches i posted but you dont want to.

the closest to a discussion where remis replies to my patches
and of course the other proposals for vote options.
if 10 people would reply and state their preferrance and i mean
10 random people not everyone from "one side" of the main disagreement
then i would have a better feeling what people prefer
and assuming that points to one or 2 clear directions then i could
suggest options that are targetet to these oppinions.

But people like boykoting my suggestion for trying to move this
forward first by discussion and consensus. That may fail but its
failure will give us knowledge what needs to be in the vote

So yes, these options are for the people not for me.

Also, extra options do no harm in a condorcet vote, it gives noone
an advanatge. It might just result in a outcome that represents the
will of more people

thx

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-03-05 03:36:14)
> On Mon, Mar 04, 2024 at 10:15:31PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-03-04 00:36:21)
> > > [words words]
> > 
> > Again - why do you personally need so many choices? Just one should be
> > enough. If someone else wants some other choice on the ballot, they
> > should ask for it.
> 
> Many people do not speak up,

And they need you to read their minds and speak for them? I see no
evidence for this.

> Also there has not been a real discussion from which i can see what the
> community prefers.

That's what the vote is supposed to do. The discussion shows there are
fundamental disagreements that cannot be resolved otherwise.

> I asked you to comment on the patches i posted but you dont want to.

I did comment. My comment is that your approach amounts to derailing and
hijacking this discussion, and I wish you did not do that because it is
rude and adds unnecessary chaos and confusion.

> the closest to a discussion where remis replies to my patches
> and of course the other proposals for vote options.

That IS the discussion. If its content is not to your liking then it's a
problem with you, not the discussion.

> if 10 people would reply and state their preferrance and i mean
> 10 random people not everyone from "one side" of the main disagreement

Who is "one side"? This thread has 10+ authors who expressed their
opinions and concerns, and some proposed their preferred alternatives
for the vote. Note how nobody except you has a problem with going
forward with the vote.

> then i would have a better feeling what people prefer

That's what the vote is supposed to accomplish.

> and assuming that points to one or 2 clear directions then i could
> suggest options that are targetet to these oppinions.

So you're implying there are these poor oppressed masses who are unable
to speak their opinion and need you to read their minds and be their
champion? You are insulting our community you know, they are not
helpless toddlers.

> But people like boykoting my suggestion for trying to move this
> forward first by discussion and consensus. That may fail but its
> failure will give us knowledge what needs to be in the vote
> 
> So yes, these options are for the people not for me.

I've read about many instances of someone claiming to speak for "the
people", "the oppressed", "the proletariat", etc. Somehow they never
actually do.

> Also, extra options do no harm in a condorcet vote, it gives noone
> an advanatge. It might just result in a outcome that represents the
> will of more people

Extra options mean extra burden on the voters. Our turnouts are already
not great, adding filler options that nobody actually wants can reduce
it further.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Sun, Mar 03, 2024 at 03:49:33AM +0100, Michael Niedermayer wrote:
[...]

> +If a TC member is aware of a conflict of interest with regards to the case, they must announce it
> +and recuse themselves from the TC discussion and vote.

please replace this in my proposal by this (as it clearer states what the intend is)

> * If a TC member is aware of being in a conflict of interest with regards to the case, they must announce it
> and recuse themselves from the TC discussion and vote.

(also as you can see we have active discussions here, the vote is IMHO
 premature)

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Vittorio Giovara]

On Mon, Mar 4, 2024 at 1:57 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Sun, Mar 03, 2024 at 03:49:33AM +0100, Michael Niedermayer wrote:
> [...]
>
> > +If a TC member is aware of a conflict of interest with regards to the
> case, they must announce it
> > +and recuse themselves from the TC discussion and vote.
>
> please replace this in my proposal by this (as it clearer states what the
> intend is)
>
> > * If a TC member is aware of being in a conflict of interest with
> regards to the case, they must announce it
> > and recuse themselves from the TC discussion and vote.
>
> (also as you can see we have active discussions here, the vote is IMHO
>  premature)
>

we literally had premature voting for STF, despite multiple discussions
taking place during the time
I don't see how a parallel thread here should stop the proposed vote now
please let's stop filibustering and just move on to voting
-- 
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Mon, Mar 04, 2024 at 10:45:02AM +0100, Vittorio Giovara wrote:
> On Mon, Mar 4, 2024 at 1:57 AM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > On Sun, Mar 03, 2024 at 03:49:33AM +0100, Michael Niedermayer wrote:
> > [...]
> >
> > > +If a TC member is aware of a conflict of interest with regards to the
> > case, they must announce it
> > > +and recuse themselves from the TC discussion and vote.
> >
> > please replace this in my proposal by this (as it clearer states what the
> > intend is)
> >
> > > * If a TC member is aware of being in a conflict of interest with
> > regards to the case, they must announce it
> > > and recuse themselves from the TC discussion and vote.
> >
> > (also as you can see we have active discussions here, the vote is IMHO
> >  premature)
> >
> 
> we literally had premature voting for STF, despite multiple discussions
> taking place during the time

The STF opertunity had a deadline.
Also we can already start discussing what shall be done when the next grant
opertunity comes. I dont know if we will be accepted, so its possible
1. that if we are rejected that we will hear of that narrowly before the
next deadline.
2. there is always the chance for more opertunities, we should be ready
to know what we want next time


> I don't see how a parallel thread here should stop the proposed vote now
> please let's stop filibustering and just move on to voting

voting on what ?

With a simple yes/no vote one can maybe just vote but this is a complex
change to the committee rules about conflict of interrest, who can vote
and who not, if everyone can just flip a coin and decide or if theres
a rule to follow. If members can vote on things they themselves are
involved in, in their own disagreements they have with others.

A discussion allows people to find others points of view, and refine
their own. Its essential even if no consensus is found, dont you agree ?

Iam not blocking the vote btw, i suggested several options for it.
What i think is that a real discussion would make sense before the vote
if no such discussion happens and the vote moves forward with all options
then that will work out too i guess.

thx

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-03-05 03:50:01)
> The STF opertunity had a deadline.
> Also we can already start discussing what shall be done when the next grant
> opertunity comes.

How about some actual transparency instead of backroom deals, for a
change.

The application has apparently been submitted, with no public
announcement that it even happened, much less what was in it.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer via ffmpeg-devel]

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

On Tue, Mar 05, 2024 at 11:27:22AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-03-05 03:50:01)
> > The STF opertunity had a deadline.
> > Also we can already start discussing what shall be done when the next grant
> > opertunity comes.
> 
> How about some actual transparency

Theres a wiki:
https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
that contains an application
only 2 people filled out the application

also Pierre collected the SoWs, only 2 people submitted any SoWs

I do remember asking you to submit something and IIRC you said that you
are waiting for the vote outcome. But you never submitted anything
I also tried to contact everyone else, who at the time had something incomplete
on the wiki and their name.

This (and other people also not submitting any SoWs) caused us to fall below
teh 150k€ minimum so i tried to fill the missing space with added work
so we reach the minimum.

at night on the 12th/morning 13th february i was CC-ed on the application submission to STF
" a draft corresponding to the community-driven proposals found in [wiki]."

Tara from STF then reworked this and asked us various additional information:
    (estimated effort (people hours) per milestone,
     and the fully loaded hourly rate (the price rate, so the cost divided by total number of hours).)
     "If you want to invoice after each sub milestone, then you need to break down the total cost per milestone into each sub milestone (and by extension also the estimated effort)."
Others, I and niklas then helped fill the missing things in quickly before the deadline

Someone along the line added more incomplete proposals to the wiki after the deadline
But same as with others, no SoWs where submitted, and none of the details needed in
the application where filled out.


> instead of backroom deals, for a
> change.

iam sorry, but these accusations are not acceptable
The application was and is on a public wiki
the SoWs where collected by pierre and it was publically announced before.
I tried to contact all people before the deadline who had incomplete submissions.

I think for a change you should say thanks to tara, pierre, SPI, STF and others
doing all the work. Instead of accusations.

And you should submit a proposal with SoW and all needed information
next time. Similarly others should too. The idea of this was never to have
just 2 people submit SoWs


> 
> The application has apparently been submitted, with no public
> announcement that it even happened, much less what was in it.

whats in it, should simlpy be what was on the wiki application
plus the fixes and cleanups mentioned above

thx

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Zhao Zhili]

> On Mar 7, 2024, at 07:25, Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> 
> On Tue, Mar 05, 2024 at 11:27:22AM +0100, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2024-03-05 03:50:01)
>>> The STF opertunity had a deadline.
>>> Also we can already start discussing what shall be done when the next grant
>>> opertunity comes.
>> 
>> How about some actual transparency
> 
> Theres a wiki:
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
> that contains an application
> only 2 people filled out the application
> 
> also Pierre collected the SoWs, only 2 people submitted any SoWs
> 
> I do remember asking you to submit something and IIRC you said that you
> are waiting for the vote outcome. But you never submitted anything
> I also tried to contact everyone else, who at the time had something incomplete
> on the wiki and their name.

I confirm that I have got the email from Michael. Unfortunately it’s right during
Spring festival (Chinese new year).
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Vittorio Giovara]

On Thu, Mar 7, 2024 at 12:25 AM Michael Niedermayer via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> > instead of backroom deals, for a
> > change.
>
> iam sorry, but these accusations are not acceptable
> The application was and is on a public wiki
> the SoWs where collected by pierre and it was publically announced before.
> I tried to contact all people before the deadline who had incomplete
> submissions.
>

I think the backroom deals is referring to the months of silence between
*some people* knowing and the community being informed, plus the rushed 2
weeks voting time


> I think for a change you should say thanks to tara, pierre, SPI, STF and
> others
> doing all the work. Instead of accusations.
>

I don't see anybody thanking Anton for the work trying to solve the
contentious point on the rules
If anything he keeps being disparaged by conspiracy theorists, and getting
the discussion derailed


> And you should submit a proposal with SoW and all needed information
> next time. Similarly others should too. The idea of this was never to have
> just 2 people submit SoWs
>
>
> >
> > The application has apparently been submitted, with no public
> > announcement that it even happened, much less what was in it.
>
> whats in it, should simlpy be what was on the wiki application
> plus the fixes and cleanups mentioned above
>

Can you guys open a separate thread for these points? They have nothing to
do with the case at hand.
-- 
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] [RFC] clarifying the TC conflict of interest rule

[Paul B Mahol]

On Thu, Mar 7, 2024 at 3:01 PM Vittorio Giovara <vittorio.giovara@gmail.com>
wrote:

> On Thu, Mar 7, 2024 at 12:25 AM Michael Niedermayer via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
> > > instead of backroom deals, for a
> > > change.
> >
> > iam sorry, but these accusations are not acceptable
> > The application was and is on a public wiki
> > the SoWs where collected by pierre and it was publically announced
> before.
> > I tried to contact all people before the deadline who had incomplete
> > submissions.
> >
>
> I think the backroom deals is referring to the months of silence between
> *some people* knowing and the community being informed, plus the rushed 2
> weeks voting time
>
>
> > I think for a change you should say thanks to tara, pierre, SPI, STF and
> > others
> > doing all the work. Instead of accusations.
> >
>
> I don't see anybody thanking Anton for the work trying to solve the
> contentious point on the rules
> If anything he keeps being disparaged by conspiracy theorists, and getting
> the discussion derailed
>
>
> > And you should submit a proposal with SoW and all needed information
> > next time. Similarly others should too. The idea of this was never to
> have
> > just 2 people submit SoWs
> >
> >
> > >
> > > The application has apparently been submitted, with no public
> > > announcement that it even happened, much less what was in it.
> >
> > whats in it, should simlpy be what was on the wiki application
> > plus the fixes and cleanups mentioned above
> >
>
> Can you guys open a separate thread for these points? They have nothing to
> do with the case at hand.
>

Thanks for confirming complete lack of transparency on all aspects in this
undead project.


> --
>
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".
>
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Vittorio Giovara]

On Tue, Mar 5, 2024 at 3:50 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Mon, Mar 04, 2024 at 10:45:02AM +0100, Vittorio Giovara wrote:
> > On Mon, Mar 4, 2024 at 1:57 AM Michael Niedermayer <
> michael@niedermayer.cc>
> > wrote:
> >
> > > On Sun, Mar 03, 2024 at 03:49:33AM +0100, Michael Niedermayer wrote:
> > > [...]
> > >
> > > > +If a TC member is aware of a conflict of interest with regards to
> the
> > > case, they must announce it
> > > > +and recuse themselves from the TC discussion and vote.
> > >
> > > please replace this in my proposal by this (as it clearer states what
> the
> > > intend is)
> > >
> > > > * If a TC member is aware of being in a conflict of interest with
> > > regards to the case, they must announce it
> > > > and recuse themselves from the TC discussion and vote.
> > >
> > > (also as you can see we have active discussions here, the vote is IMHO
> > >  premature)
> > >
> >
> > we literally had premature voting for STF, despite multiple discussions
> > taking place during the time
>
> The STF opertunity had a deadline.
>

a deadline that you were aware of for months, and dumped on the community
saying "we only have 2 weeks to decide" and *while we were discussing the
options* you single handedly started a vote


> Also we can already start discussing what shall be done when the next grant
> opertunity comes. I dont know if we will be accepted, so its possible
> 1. that if we are rejected that we will hear of that narrowly before the
> next deadline.
> 2. there is always the chance for more opertunities, we should be ready
> to know what we want next time
>

We are NOT discussing this topic in this thread, please stop trying to
derail the conversation


> > I don't see how a parallel thread here should stop the proposed vote now
> > please let's stop filibustering and just move on to voting
>
> voting on what ?
>

On the list of options that Anton is preparing


> Iam not blocking the vote btw, i suggested several options for it.
> What i think is that a real discussion would make sense before the vote
> if no such discussion happens and the vote moves forward with all options
> then that will work out too i guess.
>

Including expanding the GA, sending separate patches, and now mentioning
funding in this very response
I love the chaos as much as anybody but we need to be practical at a
certain point.

Either add an option to the proposed list of options or let's move to
voting.
-- 
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

Hi Vittorio

On Tue, Mar 05, 2024 at 01:44:52PM +0100, Vittorio Giovara wrote:
> On Tue, Mar 5, 2024 at 3:50 AM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > On Mon, Mar 04, 2024 at 10:45:02AM +0100, Vittorio Giovara wrote:
> > > On Mon, Mar 4, 2024 at 1:57 AM Michael Niedermayer <
> > michael@niedermayer.cc>
> > > wrote:
> > >
> > > > On Sun, Mar 03, 2024 at 03:49:33AM +0100, Michael Niedermayer wrote:
> > > > [...]
> > > >
> > > > > +If a TC member is aware of a conflict of interest with regards to
> > the
> > > > case, they must announce it
> > > > > +and recuse themselves from the TC discussion and vote.
> > > >
> > > > please replace this in my proposal by this (as it clearer states what
> > the
> > > > intend is)
> > > >
> > > > > * If a TC member is aware of being in a conflict of interest with
> > > > regards to the case, they must announce it
> > > > > and recuse themselves from the TC discussion and vote.
> > > >
> > > > (also as you can see we have active discussions here, the vote is IMHO
> > > >  premature)
> > > >
> > >
> > > we literally had premature voting for STF, despite multiple discussions
> > > taking place during the time
> >
> > The STF opertunity had a deadline.
> >
> 

> a deadline that you were aware of for months, and dumped on the community
> saying "we only have 2 weeks to decide"

There was a zoom call or something, i think in january, i was not part of
and i also never saw a recording of it.
on the 22th january i got a mail from someone who was on that call and who
summarized it for several people who where not on the call, that said that
STF wanted our application by the end of january.

On the 25th January, we where told the meeting was delayed and would
happen on teh 14th february.
And on the 27th january at night (you could call it 28th morning)
i posted about the Souvereign tech fund.

So, iam sorry, but i knew of this deadline exatly 2-3 days longer than the
rest of teh world. Not months. I knew some people where discussing with STF,
yes but if you expect them to have made this public at an early stage, you
need to complain to them. Not me, who also wanted this to be more public earlier.

Thx


> and *while we were discussing the
> options* you single handedly started a vote

[...]

--
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Michael,
following up on the previous discussion in this thread - if you,
personally, would like to vote for a different option than those
suggested so far, please propose one.
I am not going to add a large number of options that nobody actually
wants to vote for, as it imposes a burden on the voters who have to
carefully read and compare all the options.

Beyond that, I am planning to start the vote on Monday 2024-03-25.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Nicolas George]

Anton Khirnov (12024-03-22):
> I am not going to add a large number of options that nobody actually
> wants to vote for, as it imposes a burden on the voters who have to
> carefully read and compare all the options.

The one organizing the vote should not be one of the persons defending
an option.

Please let somebody else do it.

-- 
  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] [RFC] clarifying the TC conflict of interest rule

[Gyan Doshi]

On 2024-03-22 06:22 pm, Anton Khirnov wrote:
> Michael,
> following up on the previous discussion in this thread - if you,
> personally, would like to vote for a different option than those
> suggested so far, please propose one.
> I am not going to add a large number of options that nobody actually
> wants to vote for, as it imposes a burden on the voters who have to
> carefully read and compare all the options.
>
> Beyond that, I am planning to start the vote on Monday 2024-03-25.

Please do post the final text and options a day in advance.

Regards,
Gyan

_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Gyan Doshi (2024-03-22 14:05:05)
> Please do post the final text and options a day in advance.

I have now created the poll, but not started it yet (the text and
options can still be edited). It looks like this:

Description:

There is disagreement about the appropriateness and interpretation of
the following sentence in Technical Committee rules
(doc/community.texi):

    If the disagreement involves a member of the TC, that member should
    recuse themselves from the decision.

(see thread starting from Message-Id
<170841737762.27417.14992162535824834057@lain.khirnov.net> for more
details)

How should this sentence be changed? Rank the options below (labeled by
the developer who proposed them) in your order of preference.

Nicolas

Any member of the TC who had a strong opinion on the question raised
before it was raised should recuse themselves.

In particular, must recuse themselves any member of the TC who:

* participated in the discussion (on the ML, on IRC or elsewhere) in a
  specific direction (minor comments and questions being acceptable);
* has a personal interest in the outcome;
* is, was recently or soon will be employed by an entity having a
  personal interest in the outcome or has any kind of hierarchical
  relationship with such entity.

Failure to do so would result, upon discovery, into the exclusion of all
FFmpeg governance bodies, including the general assembly, for a duration
of no less than five years.

Additionally, any member of the general assembly can recuse any member
of the TC without having to provide a reason.

If the application of these rules result in all members of the TC
recused or if the remaining members do not feel comfortable being too
few, that means the project is in a crisis of trust that needs to be
resolved by the general assembly.

Gyan

Any member of the TC who has

* had a major participation in the discussion or demonstrated a partisan
  disposition on the concerned issue at any public venue, or
* a material interest in the resolution of the dispute, either directly
  or via current or anticipated employment or consideration

should be recused from participation in the TC activities related to the
concerned matter. This recusal may be effected either directly by the TC
member, or failing which, by a vote of the Community Committee (CC) -
the TC member must not participate in any such vote. Failure by the TC
member to reveal any such involvement as described above, if judged
intentional and material by the CC, shall result in exclusion of said
member from all FFmpeg governance bodies for a period of no less than
two years.

Anton

Each TC member must vote on such decision according to what is, in their
view, best for the project.

If a TC member feels they are affected by a conflict of interest with
regards to the case, they should announce it and recuse themselves from
the TC discussion and vote.

A conflict of interest is presumed to occur when a TC member has a
personal interest (e.g. financial) in a specific outcome of the case.

Michael 1

Each TC member must vote on such decision according to what is, in their
view, best for the project.

If a TC member is aware of being in a conflict of interest with regards
to the case, they must announce it and recuse themselves from the TC
discussion and vote.

A conflict of interest is presumed to occur when a TC member has a
personal interest (e.g. financial) in a specific outcome of the case
that differs from what is best for the project.

If the disagreement involves a member of the TC, that member must recuse
themselves from the decision.

Michael 2

Each TC member must vote on such decision according to what is, in their
view, best for the project.

If a TC member is aware of being in a conflict of interest with regards
to the case, they must announce it and recuse themselves from the TC
discussion and vote.

A conflict of interest is presumed to occur when a TC member has a
personal interest (e.g. financial) in a specific outcome of the case
that differs from what is best for the project.

Notes

The difference between Michael 1 and Michael 2 is only that 1 has an
extra sentence at the end (the original disputed sentence with
should→must).

The difference between Michael 2 and Anton is in the second sentence
("is aware" vs. "feels") and third sentence (Michael 2 has "that differs
from what is best for the project.") at the end.

Candidates:

The top choice will win.

* Nicolas
* Gyan
* Anton
* Michael 1
* Michael 2
* left as is
* removed without replacement

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Gyan Doshi]

On 2024-03-25 03:11 pm, Anton Khirnov wrote:
> Quoting Gyan Doshi (2024-03-22 14:05:05)
>> Please do post the final text and options a day in advance.
> I have now created the poll, but not started it yet (the text and
> options can still be edited). It looks like this:

The description, my option looks fine.

What will be the evaluation method?

Regards,
Gyan

_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Gyan Doshi (2024-03-25 13:10:28)
> What will be the evaluation method?

If you mean the Condorcet completion method, we've used Schulze in the
previous votes.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Fri, Mar 22, 2024 at 01:52:55PM +0100, Anton Khirnov wrote:
> Michael,

> following up on the previous discussion in this thread - if you,
> personally, would like to vote for a different option than those
> suggested so far, please propose one.

The goal of the vote is to find the option which most people prefer.
Not the option that I personally prefer.
The winning options often are compromises that noone has as their
favorite but the team as a whole prefers.

You also added 3 options yourself, which i presume you dont all
intend to vote for yourself


> I am not going to add a large number of options that nobody actually
> wants to vote for, as it imposes a burden on the voters who have to
> carefully read and compare all the options.

The intend of the vote here is to resolve a disagreement we have.

Simply omiting opposing options is not how Democracy works

You could discuss with others and try to find a smaller set of options
that still represent all cases the team may want.

I think the 2 main cases from the ones proposed by me are:
(that is just my feeling and i cant read peoples minds and there may be
 other preferrances that should be represented)


@@ -82,6 +82,14 @@ The TC has 2 modes of operation: a RFC one and an internal one.

 If the TC thinks it needs the input from the larger community, the TC can call for a RFC. Else, it can decide by itself.

+Each TC member must vote on such decision according to what is, in their view, best for the project.
+
+If a TC member is aware of being in a conflict of interest with regards to the case, they must announce it
+and recuse themselves from the TC discussion and vote.
+
+A conflict of interest is presumed to occur when a TC member has a personal interest
+(e.g. financial) in a specific outcome of the case that differs from what is best for the project.
+
+If the disagreement involves a member of the TC, that member must recuse themselves from the decision.
-If the disagreement involves a member of the TC, that member should recuse themselves from the decision.

 The decision to use a RFC process or an internal discussion is a discretionary decision of the TC.



@@ -82,6 +82,13 @@ The TC has 2 modes of operation: a RFC one and an internal one.

 If the TC thinks it needs the input from the larger community, the TC can call for a RFC. Else, it can decide by itself.

+Each TC member must vote on such decision according to what is, in their view, best for the project.
+
+If a TC member is aware of being in a conflict of interest with regards to the case, they must announce it
+and recuse themselves from the TC discussion and vote.
+
+A conflict of interest is presumed to occur when a TC member has a personal interest
+(e.g. financial) in a specific outcome of the case that differs from what is best for the project.
+
-If the disagreement involves a member of the TC, that member should recuse themselves from the decision.

 The decision to use a RFC process or an internal discussion is a discretionary decision of the TC.


thx

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-03-24 03:21:50)
> On Fri, Mar 22, 2024 at 01:52:55PM +0100, Anton Khirnov wrote:
> > Michael,
> 
> > following up on the previous discussion in this thread - if you,
> > personally, would like to vote for a different option than those
> > suggested so far, please propose one.
> 
> The goal of the vote is to find the option which most people prefer.
> Not the option that I personally prefer.

My point is that you should suggest options that you personally prefer,
not invent options for some imaginary people who cannot speak for
themselves. There is no evidence of them existing.

> You also added 3 options yourself, which i presume you dont all
> intend to vote for yourself

Keeping the line without change and deleting it entirely seem like
obvious "null" choices to me, but I can remove them if you prefer.

> Simply omiting opposing options is not how Democracy works

You're misrepresenting my point. It's not about "opposing" options, I
have no issue with adding those suggested by Nicolas or Gyan. I have an
issue with options that nobody actually wants.

> You could discuss with others and try to find a smaller set of options
> that still represent all cases the team may want.

The discussion already happened. We have all the options that actual
people have actually wanted. So kindly stop this obstructionism.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

Hi Anton

On Sun, Mar 24, 2024 at 12:40:52PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-03-24 03:21:50)
> > On Fri, Mar 22, 2024 at 01:52:55PM +0100, Anton Khirnov wrote:
> > > Michael,
> > 
> > > following up on the previous discussion in this thread - if you,
> > > personally, would like to vote for a different option than those
> > > suggested so far, please propose one.
> > 
> > The goal of the vote is to find the option which most people prefer.
> > Not the option that I personally prefer.
> 
> My point is that you should suggest options that you personally prefer,
> not invent options for some imaginary people who cannot speak for
> themselves. There is no evidence of them existing.
> 
> > You also added 3 options yourself, which i presume you dont all
> > intend to vote for yourself
> 
> Keeping the line without change and deleting it entirely seem like
> obvious "null" choices to me, but I can remove them if you prefer.

Thats exactly my point, you add
* your option
* several default options you expect not to win
* then gyans and nicolas options
* and then you refuse to add my 2 suggested options

This is not a democratic vote at this point. You have to add my 2 options too


> 
> > Simply omiting opposing options is not how Democracy works
> 
> You're misrepresenting my point. It's not about "opposing" options, I
> have no issue with adding those suggested by Nicolas or Gyan. I have an
> issue with options that nobody actually wants.

this started with you being asked to recuse yourself from a TC vote by
multiple people (at least 3 IIRC)
and now you want to change the rules after exactly that
and its not options that support you nor is it NULL options that you
object to. Its also not nicolas suggestion (which is probably too radical
to find a majority).
That leaves your and gyans suggestion the only 2 that are likely to win.

I think the 2 options i list are very good compromise options. They
use clearer language (no "should", no rules apply only when one feels it
but also no 2 year exclusion)


> 
> > You could discuss with others and try to find a smaller set of options
> > that still represent all cases the team may want.
> 
> The discussion already happened.

As a member of the team i remember no discussion to reduce the number of options.
I remember only you here that you decided by yourself not to include them


> We have all the options that actual
> people have actually wanted.

I certainly am an actual person and i do want my option that iam proposing.


> So kindly stop this obstructionism.

So kindly add the 2 options i asked for.

thx

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

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk


[-- 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Michael Niedermayer (2024-03-25 00:44:20)
> > We have all the options that actual
> > people have actually wanted.
> 
> I certainly am an actual person and i do want my option that iam proposing.
> 
> 
> > So kindly stop this obstructionism.
> 
> So kindly add the 2 options i asked for.

You have repeatedly said yourself that you are adding those options for
some imaginary "the people", not for yourself.

But anyway, in the interest of not prolonging this any further I have
now created the poll with your two options.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

The vote has been started, with the voter list generated by
general_assembly.pl:
# GA for 2021-01-01T00:00:00/2024-01-01T00:00:00; 50 people; SHA256:e63c3589d48557b90767f581eb1372c6c883ab87395dade38c61d0db0771fabd; HEAD:f872b1971401817356708b8863dff4ee6bd02600

If you are in the GA and have not received an email by the end of the
day, please let me know.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Tue, Mar 26, 2024 at 09:20:46AM +0100, Anton Khirnov wrote:
> The vote has been started, with the voter list generated by
> general_assembly.pl:
> # GA for 2021-01-01T00:00:00/2024-01-01T00:00:00; 50 people; SHA256:e63c3589d48557b90767f581eb1372c6c883ab87395dade38c61d0db0771fabd; HEAD:f872b1971401817356708b8863dff4ee6bd02600
> 
> If you are in the GA and have not received an email by the end of the
> day, please let me know.

Id like to use this mail here to ask everyone to vote :)
(if you dont care about the outcome and find this dumb, you can vote all options equal too)

(and yes i got exactly 1 mail)

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

This is a reminder that I'm planning to end the vote on Monday morning.
We have 17 votes so far, if you have not voted yet please do so ASAP.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Fri, Mar 29, 2024 at 12:39:31PM +0100, Anton Khirnov wrote:
> [...] if you have not voted yet please do so ASAP.

+1

[...]
-- 
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

Hi all,

the vote has now ended with 23 votes cast, results are available at
https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589

The winning option is 'Anton', i.e. my proposal. Voting data as reported
by CIVS is attached to this email for future reference.

Cheers,
-- 
Anton Khirnov

[-- Attachment #2: civs_ballots.csv --]
[-- Type: text/csv, Size: 400 bytes --]

Nicolas,Gyan,Anton,Michael 1,Michael 2,left as is,removed without replacement
7,6,2,4,3,5,1
7,7,1,7,3,4,2
5,4,2,1,3,7,7
7,6,1,5,2,5,3
7,6,1,4,2,3,5
7,6,1,5,3,4,2
7,6,1,3,2,4,5
7,6,3,5,4,1,2
2,1,6,3,5,4,7
7,7,1,7,1,7,7
7,5,1,4,2,3,6
6,6,2,3,1,4,5
7,7,1,7,7,7,7
4,3,6,1,2,5,7
7,7,1,3,2,4,7
2,1,3,5,4,6,7
1,2,7,3,5,4,7
7,6,1,5,2,4,3
7,7,7,7,7,7,7
1,2,5,3,4,6,7
7,7,1,7,1,3,7
1,2,7,3,5,4,5
7,7,1,7,6,3,2

[-- Attachment #3: 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] [RFC] clarifying the TC conflict of interest rule

[Gyan Doshi]

On 2024-04-01 04:46 pm, Anton Khirnov wrote:
> Hi all,
>
> the vote has now ended with 23 votes cast, results are available at
> https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
>
> The winning option is 'Anton', i.e. my proposal. Voting data as reported
> by CIVS is attached to this email for future reference.

How come there's an entry with all 7s?
The choices were ranks, not weight markers.

Regards,
Gyan

_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Anton Khirnov]

Quoting Gyan Doshi (2024-04-01 14:20:01)
> On 2024-04-01 04:46 pm, Anton Khirnov wrote:
> > Hi all,
> >
> > the vote has now ended with 23 votes cast, results are available at
> > https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
> >
> > The winning option is 'Anton', i.e. my proposal. Voting data as reported
> > by CIVS is attached to this email for future reference.
> 
> How come there's an entry with all 7s?
> The choices were ranks, not weight markers.

I think "last rank for all choices" is the default state, so the voter
probably just clicked submit without changing anything.

-- 
Anton Khirnov
_______________________________________________
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] [RFC] clarifying the TC conflict of interest rule

[Michael Niedermayer]

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

On Mon, Apr 01, 2024 at 01:16:48PM +0200, Anton Khirnov wrote:
> Hi all,
> 
> the vote has now ended with 23 votes cast, results are available at
> https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
> 
> The winning option is 'Anton', i.e. my proposal. Voting data as reported
> by CIVS is attached to this email for future reference.

Congratulations! :)

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates

[-- 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] [RFC] clarifying the TC conflict of interest rule

[Paul B Mahol]

On Mon, Apr 1, 2024 at 4:59 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Mon, Apr 01, 2024 at 01:16:48PM +0200, Anton Khirnov wrote:
> > Hi all,
> >
> > the vote has now ended with 23 votes cast, results are available at
> > https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
> >
> > The winning option is 'Anton', i.e. my proposal. Voting data as reported
> > by CIVS is attached to this email for future reference.
>
> Congratulations! :)
>
>
Next time prepare more voting bots than opponent, than you will surely win
again.


> thx
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
> _______________________________________________
> 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] [RFC] clarifying the TC conflict of interest rule

[Paul B Mahol]

On Mon, Apr 1, 2024 at 1:17 PM Anton Khirnov <anton@khirnov.net> wrote:

> Hi all,
>
> the vote has now ended with 23 votes cast, results are available at
> https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
>
> The winning option is 'Anton', i.e. my proposal. Voting data as reported
> by CIVS is attached to this email for future reference.
>

As expected...


>
> Cheers,
> --
> Anton Khirnov
> _______________________________________________
> 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".