Change Github teams management strategy

[vivalareda]

For all active repos, the reviewer list should contain the Github teams (such as all, devops, frontend)

[SonOfLope]

This can be done with a CODEOWNERS file. It can even be segmented according to specific folders, file extensions (so anything inside a .github folder in a repo should include devops team). It cannot be set organisation wide. Do we still want this ? We could set up a script with the github api to accelerate the process. Something like this.

[rngadam]

@SonOfLope CODEOWNERS sets automatic reviewers.

Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. Code owners are not automatically requested to review draft pull requests.

Yes, CODEOWNERS is a good case for .github/ changes always having the devops team but at issue here is more that the dropdown does not have the teams:

This is set through teams accessing the repository:

https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-team-access-to-an-organization-repository

I also note that you were NOT part of the devops team:

Just added you. This is a problem in our process/documentation.

[SonOfLope]

I dont think teams can be assign to an issue, only reviewers in Pull request. Also the description of this issues states : 'the reviewer list' meaning the scope of this issue is for pull request's and thus, CODEOWNERS file would be the way to implement this.

Just added you. This is a problem in our process/documentation.

We could also have a github workflow to add a member to the organisation with a form asking for the member`s role (frontend, backend,database,devops, etc.). That would be a new way of integrating a new member.

[rngadam]

I dont think teams can be assign to an issue, only reviewers in Pull request. Also the description of this issues states : 'the reviewer list' meaning the scope of this issue is for pull request's and thus, CODEOWNERS file would be the way to implement this.

oops, you're right.

Going back to one of your earlier comment, we wouldn't this organization-wide as we want reviewers segmented by role. so nachet-frontend should be reviewed by the frontend team and nachet team, finesse-backend by the backend team and finesse team, etc. Needs to be customized by repo. Guess you could figure out the teams based on the repo name if we follow a standard - naming convention (and ignore repos that don't follow this convention).

We could also have a github workflow to add a member to the organisation with a form asking for the member`s role (frontend, backend,database,devops, etc.). That would be a new way of integrating a new member.

Yes, create a separate issue if you haven't already.