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.

[palmskog]

Let's say Coq-community grows to dozens of projects with as many or more maintainers. It may happen that someone, adversarially or not, does something unwanted to a repository, such as removing it, moving it, corrupting it, etc.

Is there any periodic snapshotting being done of our repositories to restore from? I know various efforts try to archive open source code, but is there an easily accessible one with frequent updates we can use to restore repos from? Arguably we should document this somewhere.

[Zimmi48]

If it is code that you are talking about, I could easily set up mirrors of the coq-community repositories on gitlab.com. That wouldn't be sufficient to preserve meta-data such as issues though.

[palmskog]

@Zimmi48 I'm primarily concerned with the code and commit metadata, but obviously issues and wikis matter as well, even though GitHub seems to keep a lot of history on those. It should be possible to script periodic dumping and copying of metadata using GitHub's API, right? Maybe something to work on at an upcoming workshop. Is this being done for Coq repos, by the way?

I'm all for mirroring at GitLab, but does that cover the "snapshotting" part of the problem? For example, if a repo gets corrupted in some way, the mirror could soon contain only the corrupt version, depending on how it's set up.

[Zimmi48]

GitLab's mirroring feature includes options to mirror even force-pushes and deletions, or to only mirror normal pushes and never delete anything. In this latter case, all the information is there to recover in case of accident. However, that could produce wrong alerts if people push topic branches and force-push to them. GitHub's wikis are also git repositories so it is easy to setup a similar mirror.

GitHub does indeed keep a lot of history, in particular in its timeline, but it also allows repository administrators to delete previous edits, comments, issues, and repositories themselves. That's why I was asking whether we should restrict coq-community members' default privileges from admin to write.

Copying issue data using GitHub's API is possible and there are actually already a few services that do it for a fee (e.g. https://github.com/marketplace/backhub). I could also extend @coqbot to do it, but we would need to discuss the design (what to save, how to react to edits, deletions...).

[palmskog]

For reference, one kind of situation I had in mind for backing up repos is this.

I'm fine with GitLab mirroring, even if it doesn't capture topic branches. But I think it should be complemented by repo tarballs, e.g., once for every 30 days back.

[Zimmi48]

Why tarballs?

A good point that I read through your comment is that the more people have write-access to coq-community repositories, the more chances we take that they will be compromised if one user leaks their credentials one way or another.

[palmskog]

At least with tarballs one would know for sure: this is what the repository looked like at some specific time. With mirrors, I think one would need deep knowledge of git semantics and implementation to say something similar. For example, can't some just rewrite the reflog?

[Zimmi48]

I don't see what risk there would be if the mirror refuses to update if it's not a fast-forward. Then, you can only add stuff on top, not delete it.

[palmskog]

I see the point, but one of my points with tarballs is that it removes git from the trusted base (and I don't particularly trust git and definitely not its implementation). In any case, I don't have anything against mirrors.

[Zimmi48]

OK now I see your point.

[Zimmi48]

@palmskog I think this issue has diverged from its initial topic, and we should create a separate issue regarding backup and hide the off-topics comments from this issue. FTR I have created the GitLab coq-community organization and the mirrors for all the current repositories, as a temporary solution while waiting for a better one.

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