Define a governance process

[Zimmi48]

Meta-issue

This is not really urgent to have but it would be good to have a formal governance process at some point.
In particular, it wouldn't be surprising to have some conflicts arising about some specific projects at some point, and it would be great if this had been anticipated and the governance process included a process for conflict resolution...
We could start with a raw sketch and refine it over time like is planned for the other documents in this repository.

[palmskog]

Something that may be simple to introduce regarding governance: requiring PRs to the manifesto repo to have at least 1 approving review before merging.

It feels a bit shaky when I just open a PR and then merge after while, even if it's something small. The requirement could either be "technical" or conventional, either is fine by me.

[Zimmi48]

1 approved review from someone inside the organization and no request for changes (obviously). We can enforce this with GitHub but then it won't allow pushing commits directly even for trivialities (which may be fine). We would also need to document this: where? Should we start a new draft document "governance" with just this rule in it?

Note that this also raises the question of the process for adding new members to the coq-community organization. For now, I think I am the only one who can do this as an admin of the organization, but I don't follow a well defined process. On the other hand, we should remain relatively flexible on this aspect as well.

Another related question is the default permissions of members of the organization. For now, members have by default not just write but even admin rights on all repositories. It feels right to give write access to all repositories to all members with the idea that these rights should be used only in case the maintainer(s) are unresponsive. But what about admin rights? It felt simpler to start with to just give them to everybody as well so that the maintainer(s) have admin rights on the repositories that they are managing... (GitHub allows to define team and set different permissions for different teams.)

[anton-trunov]

We can enforce this with GitHub but then it won't allow pushing commits directly even for trivialities (which may be fine).

I'm in favor of going through PRs even for the trivialities. Because I'm not aware of a way to make GitHub send notifications for direct pushes.

[Zimmi48]

Indeed, all you get is an item in your feed on GitHub's main page. Let's do this then.

[Zimmi48]

I have created https://github.com/coq-community/manifesto/wiki/Commit,-branch-and-release-policies which includes a note about the new policy for the manifesto repo.

[Zimmi48]

I'd like to go back to the question of the default member permissions. I think it's time that not everyone is an admin of every repository, so I propose the following:

• default member permissions become write-access to all repositories;
• members retain the ability of creating / transfering repositories (this is a separate permission, and you don't need admin permissions for this);
• principal maintainers are granted admin permissions on the repositories they maintain;
• only coq-community owners are allowed to delete a repository or transfer it out of the organization (the other option is to allow repository admins to do it as well);
• we add a few others owners besides myself: I propose @palmskog and @anton-trunov.

[anton-trunov]

@Zimmi48 I think your proposal makes total sense. We can always tweak some details as we go along, right?

[palmskog]

It's indeed important to consider default member permissions, and I generally agree with the proposal by @Zimmi48.

However, do we have a criterion for what is considered a "principal maintainer"? When there's only one maintainer, this is obvious, but arguably not in other cases. Should we record maintainer status in metadata somewhere? I guess establishing criteria could fall under the "tweak" category.

[Zimmi48]

@palmskog I didn't mean "principal maintainer" as a single individual. I have always used this phrasing to carry the meaning that the maintainers of a project are not necessarily alone in maintaining it and can be helped by community contributions. Thus, here the plan is to give admin rights to whoever is listed as "maintainer" in the repo description and the meta.yml file when it exists.

[Zimmi48]

This is now done but still needs to be documented.

[palmskog]

Two governance issues I've thought about recently, and which I might propose manifesto changes for in the near future:

1. Pull requests to the manifesto repo should require approval of two of the managers (organization owners), or at the very least one owner.
2. At most one manager/owner should be a Coq core team member (being a maintainer is fine)

The rationale of (1.) is that we don't want regular members colluding to change the manifesto in radical ways. The rationale of (2.) is that we want to have Coq users as majority owners, to ensure they will consider the interests of Coq users, which may sometimes clash with those of Coq developers.