Add Project under Organisation #114

New Issue

GiteaMirror · 2025-11-02T03:09:35-06:00

GiteaMirror commented

2025-11-02 03:09:35 -06:00

Originally created by @KangoV on GitHub (Dec 7, 2016).

Currently gitea is very attractive to smaller companies (like ours) that want internal GIT hosting, but for who, github is too expensive. We are just starting down the microservices route using Domain Driven Design. This result in a few repositories which are released independently, but belong to the same project.

What I would like to see is another level underneath the Organisation. This would hold information about the project, such as url etc. A wiki and issues attached at this level would be awesome. Issues at this level are important as when an issue is reported, it may cover code in one or more repositories. We could attach each repo for which the issue depends.

Teams would still be configured at the Org level and then assigned to each project/repos.

We are using the Org level as the project with common library repos at the org level. It works but can be done better. I think this comes down to usage. Github is a public facing host with hundreds (thousands) of organisations, but within our company of course, we only have one.

Another way of doing this is to add labels to repositories. We could then have "project/my_service" and we could then filter on that.

Originally created by @KangoV on GitHub (Dec 7, 2016). Currently gitea is very attractive to smaller companies (like ours) that want internal GIT hosting, but for who, github is too expensive. We are just starting down the microservices route using Domain Driven Design. This result in a few repositories which are released independently, but belong to the same project. What I would like to see is another level underneath the Organisation. This would hold information about the project, such as url etc. A wiki and issues attached at this level would be awesome. Issues at this level are important as when an issue is reported, it may cover code in one or more repositories. We could attach each repo for which the issue depends. Teams would still be configured at the Org level and then assigned to each project/repos. We are using the Org level as the project with common library repos at the org level. It works but can be done better. I think this comes down to usage. Github is a public facing host with hundreds (thousands) of organisations, but within our company of course, we only have one. Another way of doing this is to add labels to repositories. We could then have "project/my_service" and we could then filter on that.

GiteaMirror added the type/proposal label 2025-11-02 03:09:35 -06:00

GiteaMirror closed this issue

2025-11-02 03:09:35 -06:00

GiteaMirror commented

2025-11-02 03:09:36 -06:00

@thibaultmeyer commented on GitHub (Dec 7, 2016):

Usually, organization are used like projet (eg : 1 organisation = 1 project = x repos) and gitea instance (private server) represent the company.

I think I have seen an issue about set tags to repos : #219

@thibaultmeyer commented on GitHub (Dec 7, 2016): Usually, organization are used like projet (eg : 1 organisation = 1 project = x repos) and gitea instance (private server) represent the company. I think I have seen an issue about set tags to repos : #219

GiteaMirror commented

2025-11-02 03:09:36 -06:00

@bkcsoft commented on GitHub (Dec 8, 2016):

GitLab is working on Nested Groups

Though implementing this in Gitea would be slightly hard... I think we could hack it in by internaly allowing organizations to contains /, but otherwise we need to refactor a bit...

@bkcsoft commented on GitHub (Dec 8, 2016): GitLab is working on [Nested Groups](https://gitlab.com/gitlab-org/gitlab-ce/issues/2772) Though implementing this in Gitea would be slightly hard... I think we could hack it in by internaly allowing organizations to contains `/`, but otherwise we need to refactor a bit...

GiteaMirror commented

2025-11-02 03:09:36 -06:00

@tboerger commented on GitHub (Dec 8, 2016):

Bitbucket already provides something like that

@tboerger commented on GitHub (Dec 8, 2016): Bitbucket already provides something like that

GiteaMirror commented

2025-11-02 03:09:36 -06:00

@bkcsoft commented on GitHub (Dec 9, 2016):

Issues at this level are important as when an issue is reported, it may cover code in one or more repositories.

IMO this would be the starting point, since it should be relatively easy to implement now.

One though on this though is how do we implement the API for this? since GitHub doesn't have this we'd be going outside their domain. @tboerger thoughs on that?

Another thing to consider is that we'd be getting more endpoint collisions, as all of a sudden you can't have repos named issues.

@bkcsoft commented on GitHub (Dec 9, 2016): > Issues at this level are important as when an issue is reported, it may cover code in one or more repositories. IMO this would be the starting point, since it should be relatively easy to implement _now_. One though on this though is how do we implement the API for this? since GitHub doesn't have this we'd be going outside their domain. @tboerger thoughs on that? Another thing to consider is that we'd be getting more endpoint collisions, as all of a sudden you can't have repos named `issues`.

GiteaMirror commented

2025-11-02 03:09:36 -06:00

@KangoV commented on GitHub (Feb 25, 2017):

I've successfully implemented Gitea at my workplace. Recently I'm trying to head off a move to BitBucket. Not sure how long I'll manage to resist. But multiple repositories per project is quite a desirable feature. Not as much as code reviews though :)

@KangoV commented on GitHub (Feb 25, 2017): I've successfully implemented Gitea at my workplace. Recently I'm trying to head off a move to BitBucket. Not sure how long I'll manage to resist. But multiple repositories per project is quite a desirable feature. Not as much as code reviews though :)

GiteaMirror commented

2025-11-02 03:09:37 -06:00

@camlafit commented on GitHub (May 6, 2017):

Hi

Looks nice to have a nested group structure between organization and project. In our use case we migrate from svn and to improve organization to class some project in group can be helpful.

@camlafit commented on GitHub (May 6, 2017): Hi Looks nice to have a nested group structure between organization and project. In our use case we migrate from svn and to improve organization to class some project in group can be helpful.

GiteaMirror commented

2025-11-02 03:09:37 -06:00

@lunny commented on GitHub (Sep 3, 2020):

Since #8346 merged, I think this will be easier to implemented.

@lunny commented on GitHub (Sep 3, 2020): Since #8346 merged, I think this will be easier to implemented.

GiteaMirror commented

2025-11-02 03:09:37 -06:00

@alecov commented on GitHub (Sep 28, 2022):

Bump this.

I don't really get what is the purpose of a "project" in the current design. It is literally just a kanban board with no automation whatsoever AFAIK. The "milestones" feature is another feature which also group issues in a similar fashion and with better semantics, so "projects" is a very misleading name for a feature with serves little purpose in my opinion.

I think it makes much more sense to talk about projects which aggregate multiple repositories, and per-project milestones which help delimit delivery scopes. Per-repo milestones are still useful if your project is indeed a single repo, but again, I see no purpose of having per-repo "projects" as it is now.

One workaround could be to instantiate a meta repository which serves as the project tracker, but still it is hard and confusing to keep track of repo-specific issues in this layout.

@alecov commented on GitHub (Sep 28, 2022): Bump this. I don't really get what is the purpose of a "project" in the current design. It is literally just a kanban board with no automation whatsoever AFAIK. The "milestones" feature is another feature which also group issues in a similar fashion and with better semantics, so "projects" is a very misleading name for a feature with serves little purpose in my opinion. I think it makes much more sense to talk about projects which aggregate multiple repositories, and per-project milestones which help delimit delivery scopes. Per-repo milestones are still useful if your project is indeed a single repo, but again, I see no purpose of having per-repo "projects" as it is now. One workaround could be to instantiate a meta repository which serves as the project tracker, but still it is hard and confusing to keep track of repo-specific issues in this layout.

GiteaMirror commented

2025-11-02 03:09:37 -06:00

@lunny commented on GitHub (May 14, 2023):

I think this has been resolved by #22235

@lunny commented on GitHub (May 14, 2023): I think this has been resolved by #22235

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#114