Organization-wide milestones

[zander]

Feature Description

The current scope of a 'milestone' is a single git repo. When you have multiple repositories that are part of an organization, this can become less useful. It would be nice if a single milestone could be applied to multiple repositories under the same organization.

A milestone could then be used to identify all the remaining issues for "the next release", which covers multiple repositories. It would be very useful to list all the issues assigned to this milestone in an organization and not have to go to each repo where this is duplicated.

Additionally, this allows for more scrum-like behavior, as you can then use either projects or milestones as sprints, and the other as epics.

[6543]

partial a dublicate of #13405

[delvh]

Then let's de-duplicate it by focusing this issue only on the unimplemented part, the org-wide milestone part.

[lunny]

I think it's still a proposal but not a feature. We still don't know what we want. How to create a release in the organization UI across multiple repositories? How to create this release based on different repositories with different tags?

[delvh]

The release part is rather meant as "that will be done for all repos individually". That is completely separate from the issue of org-wide milestones, and simply what many people do in praxis: Define a global milestone, and once it's closed, release all subcomponents separately but with the same version.

[lunny]

The release part is rather meant as "that will be done for all repos individually". That is completely separate from the issue of org-wide milestones, and simply what many people do in praxis: Define a global milestone, and once it's closed, release all subcomponents separately but with the same version.

Then every repository will display that release? And one repository could delete that release?

[delvh]

We are talking about completely different things. The important part is the

The release part is rather meant as "that will be done for all repos individually".

That was meant as that's simply how it is used, not as that's how it's supposed to be done. I don't want any org-wide releases, I want org-wide milestones in this issue.

[zander]

A milestone is not the same thing as a release. They can be related, for sure. But milestones are absolutely going to have usecases that are not related to a specific or even known release.

An issue can be assinged to the milestone "release v3". But an issue can be assigned to the milestone "full testing coverage". Which is completely orthoganol to the release schedule.

So the only thing that this issue asks for is being able to define and manage milestones at the organization level (parent is org), and then have projects automatically show them and allow issues to be assigned to them just like they can be assigned to project-local milestones today.

Naturally visualization of this different datastructure should also give some new opportunities for org-wide features that may be implicit here.

[stuzer05]

So the only thing that this issue asks for is being able to define and manage milestones at the organization level (parent is org), and then have projects automatically show them and allow issues to be assigned to them just like they can be assigned to project-local milestones today.

Then there should be a way to assing an issue to multiple milestones. In this case, project and org

[delvh]

That's still not what this issue is asking for… It typically works without multiple milestones for one issue, simply by using a milestone as a sprint for example. See for example Gitea: We open a new milestone for every release, and we have a lot of projects. In theory, by having org-wide milestones, we could ensure that the progress for every tool is tracked under one milestone, no "multi milestone" needed.

[stuzer05]

In theory, by having org-wide milestones, we could ensure that the progress for every tool is tracked under one milestone, no "multi milestone" needed

That's a good example, I get it now

[mbretter]

I am really excited about the organization-wide project boards in 1.19, and hoped for orga-milestones too.

Having this feature in one of the next releases would be great, because at the moment sprint planning across multiple repos is nearly impossible for us.

[sebthom]

Now that we have org-level labels, and project boards, org-level milestones are the final missing piece for multi-repo development projects/products. Hopefully this lands soon! 🤞

[KlavsKlavsen]

We use the "global milestones" overview - to have a central planning meeting across projects.. and many things actually requires changes across multiple repos - and for all those, we REALLY would appreciate having a global (org level) milestone to assign such issues to - no matter the repo - to have our nice global milestone (date sorted) overview of "whats most important right now - across all repos"

[iminfinity]

we might be able to add this by using similar design pattern used in org level projects, by adding ownerID to milestone table

[KlavsKlavsen]

We would really like some feedback if you agree on the implementation plan - before we write the PR.. Our other 4 PRs seem to be stagnating (search for Obmondo.com) - and we really don't like to run a fork of gitea - and would rather see that our improvements got merged to benefit everyone :) (and we switched from gitlab to gitea - as gitea is true open source - where we could actually then contribute to add the parts we were needing that we had in gitlab) :)

[sebthom]

@KlavsKlavsen if the PRs are not getting progressed, have you thought about offering them to Forgejo? Maybe they are interested. Might be better than having to maintain your own fork.

[denyskon]

It is really unfortunate that many PRs stay open for so long. I myself as a maintainer try to go through old PRs to finally clean up that list of 200+ open ones, but the amount of new monthly PRs doubled since a year ago with only a minor increase in the number of maintainers, so it remains hard to review all of them. Please stay patient, and you can also ask for reviews again in the PRs if they stay unnoticed for a long time - after all nobody has a complete overview :)

We're trying to optimise our processes - please don't ever think that your changes are unwanted only because nobody receives them....

[KlavsKlavsen]

@denyskon if you could open up more about the process.. and if that process made it clear how we could help in making it easier for you to merge (and feel safe doing so :) - that would help us.

We'll gladly help anyway we can - we're a small company of mainly Go programmers doing open source development for operations/SRE's - and prefer to do everything as Open Source - but if it never gets merged - its not true open source and does not really help anyone :)

We understand the dangers of merging things that haven't been properly reviewed and tested (as we do both a lot for our own code :) - Any assistance, improvement or sparring we can offer - we'll gladly hear about it and see what we can do to help.

This is also why we wanted to get the talk about implementation first - before we went a route you disagreed with - wasting everybodys time.

[delvh]

As @denyskon said already, one of the main problems Gitea faces is a shortage of PR reviewers: We would love to merge all PRs (or at least the vast majority that is well implemented, has a clear scope, and no architectural shortcomings), we simply lack the team to review all of them.

Unfortunately, I don't see a clear solution how to solve this problem: If there are more people to review, less PRs will become stale.

However, how do you motivate people to review PRs? I can only see the following options: Option 1: "Head hunting" new maintainers, except there isn't a salary and you need to let people motivate themselves to take on the "burden" of becoming a maintainer. Close to impossible when no one is paid. Option 2: Adding a "review quota", i.e. requiring a certain amount of reviews per month per maintainer. However, that makes reviews even more tedious, perhaps results in even more maintainers jumping ship, and probably has problems of its own that need to be accounted for.

If you have any other idea how to solve this problem, let me know. (If you have any spare Gitea developer at your disposal, you're also very welcome to nudge them into becoming a maintainer themselves. As already mentioned, we cannot have enough maintainers.)

[techknowlogick]

I can say that in 2022 we merged ~100 PRs per month, and in 2023 we scaled that up to ~400. We have on-boarded several new maintainers during that time too. So it's quite the active project. Although as the others have said, there are always going to be more reviewers needed.

In terms of helping a PR get merged, the easier to review the better (small PR, tests and docs included if applicable, screenshots of adding something new to user interface, etc..), and following up to code reviews. (Edit: to be clear, this isn't saying you haven't done that. These are general overall things that help PRs get reviewed.)

And apologies that your PRs have dropped off. Could you email me at (my github username)@gitea.com? If any maintainers want to see the list of PRs mentioned above, there is: https://github.com/search?q=repo%3Ago-gitea%2Fgitea++Obmondo.com&type=pullrequests

[vtolstov]

@techknowlogick please, can you say what we need to to to help get org wide milestones merged?

[lunny]

How about to use an org-level project to instead of an org-level milestone? I think we can add a new table-style UI for project like GH did. Users can switch between board mode and table mode.

[KlavsKlavsen]

@lunny do you mean to suggest we add "org level milestones" - under projects? or just like projects is added? (ie. under org level menu) - as sep. menu bullit there?

[lunny]

@lunny do you mean to suggest we add "org level milestones" - under projects? or just like projects is added? (ie. under org level menu) - as sep. menu bullit there?

I mean not to add org level milestone but let org level projects have milestone similar features. The project will have two UI. One is for columns, another is for tables or rows.

[KlavsKlavsen]

So use projects as milestones.. meaning we can't have issues from different milestones on same kanban? That would really suck for our workflow atleast :) (we have a kanban/project per team)

[KlavsKlavsen]

and within 1 milestone - typicly there is tasks for different teams - so having 1 milestone tied to 1 project would also be bad :( (and also very weird - as milestones for each repo - don't have of those limitations). IMHO org level milestones should simply work across repos - but otherwise exactly as milestones does. So a place to create them - and then they'll just be added under a "global milestone" part of the "add milestone" dialog for an issue ?

[lunny]

Ah, just know what you are using milestones and projects. It's different from my experiences.

If we have an org-level milestone, users can still assign milestone in the issue view right siderbar?

[KlavsKlavsen]

Our suggestion would allow "org level" milestones to be chosen (or repo specific milestones) in same milestone selector on issue yes. Same way it works for labels. (where there is also org level and repo level)