Hi! I’m trying to figure out the best way to structure the organization / teams on my company’s gitea instance. We have about 25 developers, split up into teams of 4-6 people. In addition to these core teams, some developers also belong to one or more “review groups” whose additional review is requested for certain kinds of projects (e.g. batch, gui, soap, rest).
- developers should have read access to all repo’s, and should be able to submit PR’s to all repo’s (would only happen occasionally to send a PR to another team’s repo, but it should be possible)
- developers should have write access only to their own team repo’s
- 1 approval from a team member is required to be able to merge and only team members can merge
- developers should be able to request additional approval on their PR from a review group if needed
- we would like to have a consistent set of labels across all repo’s (bugfix, feature, documentation, backport)
I see two options, but both have some problems.
1.) ORGANIZATION PER TEAM:
Create an organization per team. Within each organization, we define 2 teams: “Maintainers” (the core developers) and “Contributors” (all other developers). Set up branch protection to require 1 approval from a maintainer + only allow maintainer to merge.
This works, but has 2 problems:
- we would also have to define the “review group” teams in all 5 organizations, as there are no global teams in gitea
- there is an issue with the labels: these can be defined on organization level, but they are not considered the same because they have a different ID. So you cannot filter on labels across multiple organizations
2.) ONE ORGANIZATION WITH 5 TEAMS
Just create a single organization, and within it define the 5 teams + the “review groups”.
This seems like a more straightforward structure to me, and it solves the 2 problems described above, but it has its own drawback: the activity feed, issue and PR overviews are on organization level. How can I see the activity feed, open issues and PR’s for my own team only?
Are there some other drawbacks of either approach that I am overlooking? Is there another option?