Organization-wide milestones #9162

@6543 commented on GitHub (Jul 2, 2022):

partial a dublicate of #13405

@6543 commented on GitHub (Jul 2, 2022): partial a dublicate of #13405

GiteaMirror commented

@delvh commented on GitHub (Mar 5, 2023):

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

@delvh commented on GitHub (Mar 5, 2023): Then let's de-duplicate it by focusing this issue only on the unimplemented part, the org-wide milestone part.

GiteaMirror commented

@lunny commented on GitHub (Mar 5, 2023):

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?

@lunny commented on GitHub (Mar 5, 2023): 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?

GiteaMirror commented

@delvh commented on GitHub (Mar 5, 2023):

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.

@delvh commented on GitHub (Mar 5, 2023): 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.

GiteaMirror commented

@lunny commented on GitHub (Mar 5, 2023):

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?

@lunny commented on GitHub (Mar 5, 2023): > 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?

GiteaMirror commented

@delvh commented on GitHub (Mar 5, 2023):

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.

@delvh commented on GitHub (Mar 5, 2023): **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.

GiteaMirror commented

@zander commented on GitHub (Mar 5, 2023):

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.

@zander commented on GitHub (Mar 5, 2023): 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.

GiteaMirror commented

@stuzer05 commented on GitHub (Mar 6, 2023):

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

@stuzer05 commented on GitHub (Mar 6, 2023): > 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

GiteaMirror commented

@delvh commented on GitHub (Mar 6, 2023):

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.

@delvh commented on GitHub (Mar 6, 2023): 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.

GiteaMirror commented

@stuzer05 commented on GitHub (Mar 6, 2023):

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

@stuzer05 commented on GitHub (Mar 6, 2023): > 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

GiteaMirror commented

@mbretter commented on GitHub (Mar 22, 2023):

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.

@mbretter commented on GitHub (Mar 22, 2023): 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.

GiteaMirror commented

@sebthom commented on GitHub (Jun 2, 2023):

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! 🤞

@sebthom commented on GitHub (Jun 2, 2023): 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! 🤞

GiteaMirror commented

@KlavsKlavsen commented on GitHub (Sep 1, 2023):

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"

@KlavsKlavsen commented on GitHub (Sep 1, 2023): 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"

GiteaMirror commented

@iminfinity commented on GitHub (Jan 25, 2024):

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

@iminfinity commented on GitHub (Jan 25, 2024): we might be able to add this by using similar design pattern used in org level projects, by adding `ownerID` to milestone table

GiteaMirror commented

@KlavsKlavsen commented on GitHub (Jan 26, 2024):

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

@KlavsKlavsen commented on GitHub (Jan 26, 2024): 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) :)

GiteaMirror commented

@sebthom commented on GitHub (Jan 26, 2024):

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

@sebthom commented on GitHub (Jan 26, 2024): @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.

GiteaMirror commented

@denyskon commented on GitHub (Jan 26, 2024):

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

@denyskon commented on GitHub (Jan 26, 2024): 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....

GiteaMirror commented

@KlavsKlavsen commented on GitHub (Jan 26, 2024):

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

@KlavsKlavsen commented on GitHub (Jan 26, 2024): @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.

GiteaMirror commented

@delvh commented on GitHub (Jan 26, 2024):

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

@delvh commented on GitHub (Jan 26, 2024): 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.)

GiteaMirror commented

@techknowlogick commented on GitHub (Jan 28, 2024):

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

@techknowlogick commented on GitHub (Jan 28, 2024): 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

GiteaMirror commented

@vtolstov commented on GitHub (Feb 4, 2024):

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

@vtolstov commented on GitHub (Feb 4, 2024): @techknowlogick please, can you say what we need to to to help get org wide milestones merged?

GiteaMirror commented

@lunny commented on GitHub (Feb 4, 2024):

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.

@lunny commented on GitHub (Feb 4, 2024): 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.

GiteaMirror commented

@KlavsKlavsen commented on GitHub (Feb 5, 2024):

@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?

@KlavsKlavsen commented on GitHub (Feb 5, 2024): @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?

GiteaMirror commented

@lunny commented on GitHub (Feb 5, 2024):

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

@lunny commented on GitHub (Feb 5, 2024): > @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.

GiteaMirror commented