Add Project under Organisation

[KangoV]

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.

[thibaultmeyer]

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

[bkcsoft]

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...

[tboerger]

Bitbucket already provides something like that

[bkcsoft]

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.

[KangoV]

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 :)

[camlafit]

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.

[lunny]

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

[alecov]

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.

[lunny]

I think this has been resolved by #22235