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