Agree. I'm not sure how contributes to decide which issue is to be working on. Do we need to write the suggestion somewhere that "priority: high" is encouraged, or do not need to?
Thanks, ------------------------------ Su Shuang (100pah) ------------------------------ On Fri, 26 Aug 2022 at 16:31, Ovilia <oviliazh...@gmail.com> wrote: > 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 > > >
