[RFC] clarifying the TC conflict of interest rule
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
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
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".
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
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
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
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
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
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
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
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
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
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
在 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
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
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
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
Hi, On Mon, Feb 26, 2024 at 11:34 AM Anton Khirnov <anton@khirnov.net> wrote:
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
Quoting Ronald S. Bultje (2024-02-23 20:36:11) 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
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
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
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
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/
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
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.
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
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
Send warmly welcomes to old/new tyrants of FFmpeg.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
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
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.
Michael Niedermayer (12024-02-23):
Each option should provide a patch.
Fine. But the wording can be discussed too. Regards, -- Nicolas George
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
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
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
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
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
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.
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
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.
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
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
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
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.
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
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
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
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
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
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
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
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
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
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).
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
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".
On Tue, Mar 5, 2024 at 3:50 AM Michael Niedermayer <michael@niedermayer.cc> 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
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
On Mon, Mar 04, 2024 at 10:45:02AM +0100, Vittorio Giovara wrote: the 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
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 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
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
On Mon, Mar 04, 2024 at 10:45:02AM +0100, Vittorio Giovara wrote: the 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
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
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
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
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
On 2024-03-25 03:11 pm, Anton Khirnov wrote:
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
Quoting Gyan Doshi (2024-03-22 14:05:05) options can still be edited). It looks like this:
The description, my option looks fine. What will be the evaluation method? Regards, Gyan
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
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
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
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
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
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
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
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
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
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
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
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
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
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".
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".
participants (12)
-
Anton Khirnov -
Cosmin Stejerean -
Gyan Doshi -
Marton Balint -
Michael Niedermayer -
Nicolas George -
Niklas Haas -
Paul B Mahol -
Ronald S. Bultje -
Rémi Denis-Courmont -
Vittorio Giovara -
Zhao Zhili