ocaml
OCaml Language Committee: conflicts of interest
This PR proposes to amend the description of the OCaml Language Committee to add a transparency-based policy for handling conflicts of interest.
The main idea is that with the level of interconnection of the OCaml community, excluding people from the committee deliberation due to conflict of interests would be counter-productive.
However, it still seems important to the member of the committee to report such conflicts to make the committee deliberation as transparent as possible for the rest of the world.
As a small supplementary step, we also propose that the summary of the committee deliberation should be delegated to a non-conflicting member of the committee in the case where the shepherd is conflicted.
Moreover, since the clearest source of conflicts stems from shared affiliations, this PR adds an affiliation field to the list of committee member.
Any further thoughts here? I'm happy with the text written.
I'm happy with it, too. Thank you for your work on this, @Octachron!
As I am currently on holidays and I have heard few people that still wish to comment on the current proposal, I am planning to wait for the beginning of September before amending the text and merging.
@gadmm, are there some concrete changes you'd like to propose? I think you have some good ideas (e.g. I agree that consensus is preferable to voting for technical decisions), but in its current form your feedback is phrased too broadly to effectively improve the proposal.
It's also rather unreasonable to say that "we" haven't given it enough thought, and to question other people's motives. You don't know how much thought has been given, and you don't know other people's motives. I think your feedback would be more effective (and a lot shorter) if you cut out these kinds of insinuations.
We need a policy in place so that the committee can operate effectively. @Octachron's proposal introduces the essential principle, that those with a conflict of interest with a proposal can't partake in decisions about the proposal, and gives enough detail to allow decision-making to proceed. Personally, I find this kind of polymorphic principle a wiser approach than a set of processes and rules that try to anticipate every possible situation in advance.
Pragmatically, we need to agree on something to be able to start making decisions and thus serve the purpose that the Language Committee was designed for. It was already not so easy to reach a consensus on the current proposal, which is a vast improvement over having no policy at all. So I would be in favor of merging the PR as it has reached consensus. (In fact we already started acting as if the currently proposed policy was in effect) We can keep discussing this topic, and we can always evolve our policies over time as a result of those discussions.
Some more pointed feedback.
The first question concerns the motivations for introducing a CoI policy. From the public discussion of the committee on its mailing list, the CoI policy was motivated as follows:
“there's a real danger that the committee will lack credibility if we don't have a clear conflict of interest policy”
The "appearance of impropriety" argument is an effective hack: it suffices to convince people of the importance of on a CoI policy, independently of whether they agree that there is a strong risk that their collective decisions would be biased by conflict of interest. (And demonstrating the latter is more delicate and painful.) 5/5, I would not hesitate to use it again.
To give an example, a public institution such as INRIA with marked independence of its researchers and horizontality between teams and even within teams is very different from a company such as Jane Street with a hierarchy and financial dependency of its members, where one or a few individuals can authoritatively make decisions for many of its employees and contractors. I find shocking, personally, a proposal to place these institutions at the same level.
I certainly see your point, but I think that the current choice of handling all institutions and companies uniformly is simpler and could work well enough in practice. If your analysis is right, then the policies that we would end up would be a bit too strong for some members of public institutions, and too weak for members of private companies. As a member of a public institution myself, I am okay with the costs that result on my side, and I would feel conflicted (ha!) in pushing for differentiated policies. The idea of treating INRIA differently was proposed during our synchronous meeting on this topic, but none of the affected people were particularly in favor.
I would also note that the people at INRIA who happens to sit on the committee (Florian, François and myself) have stronger bonds than merely sharing an institution, we have been frequent collaborators with about-weekly in-person meetings for years now (so tighter interpersonal links than with other github/ocaml maintainers on average), and certainly suffer from some biases coming from camaraderie. There is ample evidence that we are comfortable with publicly disagreeing with each other, but I believe the weak-conflict measures proposed are reasonable.
I was surprised some times to learn in private such ties from academic contributors that were not known publicly within the community. [...] (Disclosure: I was proposed such funding for my research activities from an industrial source, which I have declined out of various concerns including those.)
In case people wonder, one situation covered by Guillaume's description is the fact that Jane Street has provided, via the OCaml Software Foundation, the equivalent of one person-year of funding for INRIA team members who contribute to the OCaml compiler. This was mentioned in the OCSF January 2025 update, and it is relevant to mention here: because I am jointly at the initiative of this funding source (which I believe has a positive impact, and I hope will continue in the future), I have proposed to consider myself conflicted with JS proposals under the proposed conflict-of-interest policy.
I have the impression that we could start addressing some of the more specific points raised by @gadmm by adding four points:
- First, that the committee is supposed to reflect the various interests of the OCaml community from academia to the various industrial users.
- Second, we could add a short sentence stating that conflicts of interest can reduce the diversity of views in the committee, and thus should be advertised -Third, we could emphasize that consensus is the favored option, and votes should be used to inform discussions on bikeshed colours and other subjective matters. In particular, maybe we should add a point stating that the committee should agree to disagree if there no agreement on the technical merit of a proposal.
- Fourth, we should add a point that any one can raise questions on conflict of interests to the secretary.
Fine with me! I do think we could make progress by merging what we already have, and then working on these as follow-ups rather than delaying the merge. (We could click "merge" here and open a new PR for the follow-up, but this dilutes discussion. You could merge manually your existing commits into trunk/main, and then update the branch with the follow-up, to keep discussing here. I wish "merge up to
we could add a short sentence stating that conflicts of interest can reduce the diversity of views in the committee
For me the reason to be careful around conflicts of interest is that they can be a source of (often unconscious) biases, were our technical judgment is clouded by our own interests.
we should add a point that any one can raise questions on conflict of interests to the secretary.
I would be careful to discuss/mention/document this separately from the possibility to write to the secretary about our own's potential conflicts, as I think they are two very different things. (If I write to ask about whether a specific situation concerning myself is a conflict, I write in confidence and I expect a friendly discussion where the other person mostly serves to guide me to a decision through an external perspective. The description of this action should reflect this: it is safe, anyone can use it, no dumb question. If someone writes to express worry about conflict of interest involving other people, it will be a rather different interaction -- in fact I am unsure how the secretary is supposed to handle this.)
I have added an introductory paragraph that covers the first two points above, I propose to discuss the precision about voting in a second PR to make faster progress on this one.
I think we should avoid language around "unconscious bias" and "diversity" which carry connotations that are not related to the question of conflicts of interest.
Would
Conflicts of interests might introduce biases that might cloud the technical discussion.
be sufficiently neutral?
I think that is better, but I see the main danger of conflicts as biasing decisions rather than discussion. (Conflcits can affect the discussion, too, but that's a resolvable problem, because other discussants can point out weak arguments as the discussion continues.) Perhaps we could use @gasche's phrase "technical judgment"
I agree that "technical judgement" is more to the point:
Conflicts of interests might introduce biases that cloud technical judgement
?
I have amended the text as suggested, if there are no other comments, I am planning to merge by the end of the week. Of course, the door will still be open to further refinements.