OneArgo GitHub access: as open as possible, as closed as necessary

[tcarval]

OneArgo GitHub access is now publicly open :

• anyone can read issues, codes, documents, wiki
• only members can write

At ADMT-25 Triste meeting, it was mentioned that comments in discussions might be misinterpreted.
How should we set OneArgo GitHub accesses to be as open as possible, as closed as necessary.

For information @dirkslawinski @apswong @jlovellcsiro @mscanderbeg @cgourcuf

[tcarval]

Message from Dirk
Firstly, before I comment on GIT restrictions, I’d like to mention that Argo Australia is run through the CSIRO and funded via IMOS. Both organizations advocate for fully open repositories for societal good science. CSIRO is also susceptible to Freedom of Information requests for public codebases we use or contribute to, this includes all discussion boards associated with them. Having said that I do see the need for moderated discussions for sensitive topics and perhaps the public GitHub repositories are not the best place for those. There are other options available for that

There are several ways to restrict access in GIT from all the way up at the “organization” level down to the repository level. First, we need to identify which of the repo discussions we want to restrict. After that we can decide how we’d like to restrict those discussions.

The simplest is to set the organization, or repo, to not Public so only members can read the information and make comments [1] . This is heavy handed and not quite in the spirit of the openness we are aiming for, and we lose some of the free GitHub extras. However, it will prevent non-vetted members from commenting and reading. It makes all discussions private so comments cannot be taken out of context by random readers. This can only be done by an Admin who has access to the settings (gear) and organization (building) icons.

As we want the Argo Community to freely access the repo codes, we could add Moderators [2] to the discussions but that may become a burden on those who choose to, or have been assigned to, be one.

Another item to explore is setting roles [3]. This restricts posting comments but not reading comments.

One option may be to have 2 repos for each, a public one where the code and documentation sits and a private one where the discussions occur. The public one can be set to not have a discussion board.

We may need to put this to the community to see how they feel about this overall.

[1] Private repo:
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility

[2] Adding Moderators:
https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/managing-moderators-in-your-organization

[3] Roles
https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories