I think it works either using the TBD milestone or a new label meaning it should be fixed. But either way, we should face the fact that there will always be more issues opened than fixed. The way to solve this problem is by putting more effort into finding more contributors. For example, we can edit the bot that when an issue is added to the TBD milestone, it politely asks the author whether he/she is interested in fixing the problem by himself/herself so that it can be fixed sooner.
Thanks *Ovilia* On Fri, Aug 26, 2022 at 1:41 PM Yi Shen <shenyi....@gmail.com> wrote: > I think it's a great change. Leaving issues undone in the closed milestones > is not a good idea. > What I'm worrying if we put all issues that can be done in the future into > TBD milestone. It will be unmaintainable soon. But perhaps using priority: > high label can solve it. > > Thanks > > On Fri, Aug 26, 2022 at 11:36 AM Ovilia <oviliazh...@gmail.com> wrote: > > > Hi, > > > > I would like to discuss how we could improve the milestone management on > > GitHub with Apache ECharts. > > > > Currently, we have milestones named "5.3" and "5.4" and our committers > put > > issues into them when they see an issue in the issue timeline that should > > be fixed. > > But after some time, there are always more issues in the milestones than > > those > > can be actually fixed in that version. > > > > Since most of our contributors are working on the project at their > leisure > > time > > (which we are very grateful for), it would be unreasonable and impolite > to > > ask > > them to stick to the schedule. But it's also important to make sure that > > Apache > > ECharts releases are based on a relatively fixed frequency, which is two > > monthly > > for now. > > > > And more importantly, it's hard for the release manager to know which > > issues > > are related with the current version. He/she has to look through all > > commits > > to know about this information because the milestone management is > > confusing. > > > > So I would suggest: > > 1. *Remove the current milestone "5.3" and "5.4"* and move unclosed > > issues/PRs into "TBD". > > 2. *When we find issues worth fixing in the timeline, we always put* > > *them into **"TBD"*. Use the label "priority: high" for issues that > should > > be fixed with a higher priority. > > 3. *Put PRs into a milestone with version numbers only when they are* > > *merged. *For example, we are currently working towards the release of > > 5.4.0, then there should be three milestones besides "TBD": 5.4.0, 5.4.1, > > and 5.5.0. PRs that > > are targeting the "next" branch should be in 5.5.0. > > > > I would like to know what you think about this workflow. > > > > Thanks > > > > *Ovilia* > > > > > -- > Yi Shen > Apache ECharts PMC >
