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.