LGTM ~

Thanks,
------------------------------
 Su Shuang (100pah)
------------------------------



On Mon, 5 Sept 2022 at 10:47, Ovilia <oviliazh...@gmail.com> wrote:

> I think the label name "priority: high" has already explained itself.
> We don't have to encourage developers to contribute to them because
> they may not be experienced enough to fix them. Instead, we encourage the
> new contributors to fix the issues with the "difficult: easy" label, and
> this is
> stated in the GitHub Wiki.
>
> For Apache ECharts committers or experienced contributors, they can fix
> more prioritized issues first.
>
> Thanks
>
> *Ovilia*
>
>
> On Fri, Sep 2, 2022 at 1:55 AM SHUANG SU <sushuang0...@gmail.com> wrote:
>
> > 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
> > > >
> > >
> >
>

Reply via email to