Hyperledger FireFly has a microservice architecture and is comprised of many different GitHub repos. The current organizational scheme for users and permissions makes it hard to see who is responsible for what. There are several specific problems that I hope to address through these changes:

Current problems

• There is no "single source of truth" in GitHub for the list of Hyperledger FireFly maintainers. Currently, one must look in the CODEOWNERS  file in each repo to see who is in charge of a given repo. The aggregate list of all of these CODEOWNERS  is the entire list of FireFly Maintainers.
• Users in the group FireFly Committers have Write access to all FireFly repos. This level of permission is too high, meaning someone who is not a CODEOWNER on a repo can do things like create a Release in GitHub.
• If non-maintainer contributor is active in the project, they may want someone to assign issues to them. Currently they have to be on a team that is related to the project in order for someone to assign an issue to them. In the past, they have been added to the FireFly Committers team. This team has write access to FireFly repos, meaning even non-maintainers have the ability to create a release in GitHub, and manage issues and PRs

Proposed changes

• In GitHub, create a sub team called "FireFly Maintainers" the existing FireFly team. This becomes the single source of truth for all maintainers across all repos.
• In GitHub, create a sub team for each repo under the "FireFly Maintainers" team.
• The existing CODEOWNERS for each repo will be the members of each new corresponding team.
• Each new team will be given Maintain level access to their corresponding repo.
• The CODEOWNERS file will be updated in each repo to reference the new team, rather than individual users.
• The existing FireFly Committers team will be renamed to FireFly Collaborators.
• The FireFly Collaborators team will be changed to only have Read access on all FireFly repos. This still gives them the ability to open issues and PRs. This group will be used for people who want to participate in the project, have issues assigned to them, etc. but are not maintainers, and do not have write access at all.

Advantages

• This should address all the current problems listed above

Disadvantages

• Adding someone as a CODEOWNER  to a repo no longer goes through the Pull Request process. Instead, a user with the proper GitHub Organizational permissions must add the new CODEOWNER  to the proper team in GitHub. This could be an advantage or a disadvantage depending on how you look at it. It no longer takes the time of another CODEOWNER . It no longer creates extra commits in the repo history. It no longer triggers builds and tests.