Write a policy for GitHub organisation membership and teams

[nottrobin]

Write this up properly:

• Everyone within our "web & design" department should be an "owner" on the canonical-web-and-design org
• Anyone not in the "web & design" must not be an "owner"
• Anyone outside of Canonical must not be added to the canonical-web-and-design organisation at all - as either an "owner" or a "member"
• People from other departments in Canonical:
  • Must not be an "owner"
  • Can be added as a "member", but must then also be added to a "team"
• "teams" can be given access to individual repositories, but repositories must not have individual "collaborators" added directly
  • Anyone within the "web & design" department should be admin on all repositories through being an "owner" of the organisation
  • Anyone in other departments in Canonical can have write access repositories if they really need to through their "team" being added to the repository
• Any repositories with any "secrets" attached must not have any outside "teams" added

[pmahnke]

@nottrobin generally perfect... some possible exceptions

1. David Calle is like an honorary member of the team
2. Nick Vietch, at least temporaritly needs access to labels... is that possible as a member? as in to set them?

[nottrobin]

@pmahnke aren't the needs of both people solved through being members of teams added to individual repositories? Presumably even David Calle doesn't actually need access to literally every repo.

The context for this policy (which I don't think I mentioned to you yet) is because I asked Joe about keeping credentials in GitHub for the purposes of using GitHub Actions for e.g. publishing Python packages. The trouble is:

Anyone with write access to a repository can create, read, and use secrets.

From https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets

Joe said this would be okay as long as it was definitely only members of Canonical who had write access and preferably only members of our team.

For the purposes of this particular use-case, the repos we would need to be careful with are anything published to PyPi, but you can at least imagine the same model being used for NPM packages (most prominently, Vanilla), and if this goes well who knows how many other things we might want to do with other repositories.

If setting labels is the chief need we have, we could look into supporting that through a bot or connected service of some type. I've seen that on other projects, kinda like what the stalebot does.

[nottrobin]

I've discovered that it's pretty trivial to write a GitHub action to add a label based on what someone writes in a comment (here's my example). We may even be able to restrict this to certain usernames. This should mean it's quite easy to provide a way for e.g. Nick to update labels without being added to a repository.

In related news, I also found this which could be handy: https://github.com/marketplace/pr-label-enforcer

[nottrobin]

Kit ran into: https://github.com/actions/labeler/issues/12

[nottrobin]

@squidsoup: someone has proposed a workaround using https://github.com/marketplace/actions/periodic-labeler.