OCaml Language Committee: conflicts of interest

[Octachron]

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.

[shenlebantongying]

The size=80 doesn't work anymore, BTW. For example, here https://github.com/ocaml/RFCs/blob/master/Committee.md#who-is-the-committee.

[goldfirere]

Any further thoughts here? I'm happy with the text written.

[gasche]

nit: in case (1), the submitter is a person, but in case (2) it reads like it is an entity (of course we don't mean financial ties with the person submitting the proposal specifically).

[Octachron]

We could extend the synecdoche to the first sentence to make them more symmetrical:

1. being affiliated to the proposal submitter
2. ongoing or recent direct financial ties to the proposal submitter

or inline it in the second one:

1. sharing a affiliation with the proposal submitter
2. ongoing or recent direct financial ties to one of the affiliations of the proposal submitter

Do you have a preference?

[shindere]

Shoulnd't `Taking in account` be `Taking _into_ account`?

[yallop]

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!

[yallop]

As far as I can see, the document identifies the chair, but not the secretary. I think we should identify the secretary, too.

[Octachron]

I think we need to choose a secretary for the committee indeed.

[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.

[gasche]

(Maybe this is good to be merged?)

[gadmm]

Here is my feedback as promised to @Octachron. In the current state, I do not think we have given enough thought about the problem of conflicts of interests (CoI) in OCaml's situation, and the proposal does not seem ready in its current state.

The proposal focuses mainly on defining what is seen as a CoI and on the reporting of conflicts by members of the committee. In addition, it defines a uniform way of handling CoI where people recognized to be in conflict are excluded from “decisions” (votes?) but can participate in discussions.

The community should pay attention to this proposal

When we give these rules about CoI for the committee, people could meaningfully think that the same reasoning can be applied to anyone participating in the development of the OCaml language, even if the intent is that the rules only apply to the committee. In particular, the description given here of CoI and the reasoning behind the rules contain nothing that make it specific to this committee, as opposed to the broader OCaml community. To put it differently, by adopting such a broad reasoning, the committee is setting an example for the OCaml community, regardless of their original intentions. Therefore as members of the community we should pay close attention to and feel concerned by this proposal.

Making sure to have the right motivations for a CoI policy

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”

This was followed by a link to a text generated by an LLM that was initiated by the following prompt:

“What might be the consequences of a deliberative body not having a policy around conflicts of interest?”

People might legitimately ask whether we want to sincerely reflect about best practices to achieve the goals of the project, or whether we are only trying to give the impression to do something about CoI.

The general goal of a CoI policy is to avoid that a minority makes decisions for all, that correspond to the interests of the minority. There is no meaningful CoI policy without first identifying the stakeholders. This requires that we do a broader reflection about the project than is visible in this proposal.

As an example, the answer is different for a programming language advertised as “industrial-strength” (as sometimes claimed in academic papers about OCaml) than it would be for a language advertised as an academic scratchpad for experiments (as some other academic languages explicitly claim to be). To give an idea (but a reflection about the goals of OCaml might go further), for an “industrial-strength” language, people might expect the committee to represent people who would like the language to remain stable as well as people who aim to change the language.

Disclosure of CoI

The proposal requires that known conflicts of interest are made public by the chair, and institutional affiliations are recorded within the list of committee members. Committee members are also able to raise a CoI concern. However, people from outside of the committee too want to be convinced that no CoI impacts decisions, and they can raise CoI concerns whether or not there is an official process in place (in which event it is clearly better if there is a process).

We might also want, for the sake of public trust, to explicitly ask committee members to disclose the financial ties when needed. I was surprised some times to learn in private such ties from academic contributors that were not known publicly within the community. Again, this is not all-or-nothing: the conflict does not have the same impact for an academic contributor whose institution receives money from e.g. Jane Street, than for one who has a personal financial stake in an OCaml-based company. (Disclosure: I was proposed such funding for my research activities from an industrial source, which I have declined out of various concerns including those.)

The issue of handling all CoI the same

The stake of a CoI policy is less to make a list of what constitutes a CoI (for whom?) than to make sure that CoI do not impact decisions in practice thanks to the relevant measures. In particular, it is unlikely that a reflection about the impacts and remedies of each CoI would yield a uniform way to handle CoI.

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.

Investigate other ways to avoid CoI

After various kinds of CoI and their source have been identified, we could think of better ways to avoid the impact of conflicts. In particular, it is generally better to act by preventing CoI from taking hold than by excluding people after the fact.

The PR in fact admits the limitations of the proposed policy:

“with the level of interconnection of the OCaml community, excluding people from the committee deliberation due to conflict of interests would be counter-productive”

In other words, since there are so few contributors to OCaml, and they are often in CoI, we might have no other choice than to treat all CoI as weak conflicts.

Consensus rather than majority voting

Beyond lowering the committee's standards regarding CoI, which does not provide us with a solution, we might ask whether majority voting (excluding stakeholders recognized in CoI) is the best way to make decisions. The committee could develop a culture of consensus, such as the one we can find inside the governance of other programming language projects, seeking to avoid situations where a majority vote is necessary. A culture of consensus could prove less susceptible to the impact of these CoI.

Growing the community

The situation would probably not be as bad as it currently is if the OCaml community had been better at welcoming new contributors. I could point at specific instances but the committee could raise the understanding and awareness of the issue, and set the example in acting towards fixing this problem, in order to diminish the impacts of these CoI over time.

Reducing author and committee exposure to CoI for too-big-to-fail contributions

Lastly, analysing specific sources of CoI for the authors of a proposed change seems necessary. I will not go into examples here unless asked, but the following concerns are concrete.

Obviously, the degree of investment into a change affects the degree of CoI over one's own contribution. Legitimately, stakeholders might variously trust the authors of a change depending on how they bring their contribution.

For instance, incremental additions consistent with collectively agreed-upon directions are less problematic in terms of author CoI than contributions that are proposed in the form of very large unreviewable patches that underwent years of development with little community involvement. Large changes often include various choices about technical details, and those might require community feedback early on. Yet even moderate requests for amending that arrive too late can have a disproportionate cost for the authors.

Worse, poor choices in the way a contribution is brought forward can place committee members too in a situation of CoI, such as when proponents of a change are faced with such a take-it-or-leave-it situation, or when members are pressured by a build-up of hype within the community.

It is much easier to avoid such situations before they arise with rules to prevent such too-big-to-fail contributions.

In some situation the authors themselves might be more victims than responsible for the CoI, such as when some hype built-up instigated by other stakeholders can put them under a considerable amount of stress. Having measures in place to avoid such situations are thus in the interest of authors as well.

[yallop]

@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.

[gasche]

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.

[gasche]

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.

[gasche]

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.

[Octachron]

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.

[gasche]

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 and keep the PR open for the rest" was an offered option.)

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.)

[Octachron]

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.

[yallop]

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.

[Octachron]

Would

Conflicts of interests might introduce biases that might cloud the technical discussion.

be sufficiently neutral?

[yallop]

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"

[Octachron]

I agree that "technical judgement" is more to the point:

Conflicts of interests might introduce biases that cloud technical judgement

?

[Octachron]

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.