These are notes towards developing an explicit and formalized process for opam repo policy and CI changes. See ocaml/infrastructure#152 (comment) for conext and motivation.
I'll summarize what I know of the context and implicit process around the introduction of the linting check for maintainer emails. Making this implicit, ad hod practice explict can inform the articulattion of a formal process and help identify where we need to add more checks or invitaitons for input.
- The Opam-repo reviews guideline which appear to be an adjunct and extension of the maintenance policies stipulate that "the opam file should have a valid maintainer so that we can ping or send an email to them if needed". This policy was put documented at least since this Feb 14th revision of the wiki. This was well before my involvement as an opam repo maintainer, so I don't now what the process for adding this.
- IIRC, in July I asked for guidance on how we enforce this policy and how to interpret it during a maintenance meeting. The upshot of the discussion in that meeting led me to offer the PR feedback in ocaml/opam-repository#26297 (comment).
- Then, in early August, @raphael-proust opened this issue, requesting that this check be automated.
- We linked development discussions on this feature request via ocurrent/opam-ci-check#20 and ocurrent/opam-ci-check#30.
- The new linting check for emails was finally deployed in ocurrent/opam-repo-ci#350, in September, a little over a month after this issues was opened.
I see some clear short comings and problems with the way the process unfolded, but I think it is useful to start by enumerating the stages during this implicit process that provided opportunities for stakeholders to question or weigh in on the (somewhat vague) policy that was eventually written into code (under a quite narrow interpretation):
- Since February 2024, issues could have have been raised around the policy written the wiki.
- Anyone attending the regularly occurring maintenance meetings in July could have raised additional considerations or objections when I asked for guidance, and learned that email was preferred.
- In the month between when this issue was opened and when the linting check was deployed, anyone watching this repo could have raised objections on issue ocaml/infrastructure#152 or the linked issue.
- Similarly, anyone watching development on opam-repo-ci could have raised considerations on the PR that closed the latter issues, or on the PR that finally deployed the linting check.
That said, it seems to me that none of these opportunities were easy to access or observe. E.g.,
- AFAICT, there is no documented process for updating the opam repo maintenance polices, so I assume it is just at the discretion of the active maintainers to make additions or changes when they think it reasonable.
- The github wiki where the policies are recorded does not support a PR or review process, and so changes that occur there are pretty invisible, and not subject to discussion or evaluation before being committed.
- The discussion and (afaiu) clarification of this policy during the maintenance meeting does not appear to have made it into the meeting notes, which means people who were not present would have known what was discussed.
- The issues was requested on ocaml/infrastructure, even tho it pertained narrowly to the opam-repository, and perhaps that made it less visible to stakeholders who care about the package repo but not the infrastructure as a whole.
- The development to add the specific logic for this check took place on a separate repo, for several transitory, and now irrelevant reasons. Going forward, development of this kind of change will be in opam-repo-ci, making it more discoverable for interested parties.
- We did not announce the release of this change as promptly as we should have.
These are all points we can improve on.
A countervailing consideration is that the heavier we make this process, less autonomy we will have as developers and maintainers of the repo and infrastructure, and the longer it may take to get simple changes in place. That said, some regular, and open process to ensure that planned changes are visible and that there are opportunity for participation in deliberation and governance is essential.
TODO: discussing during the next repo maintainer meeting.