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

[Anton Khirnov <anton@khirnov.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
_______________________________________________
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".