Organization / teams structure

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?

Thanks

1 Like