Thank you tison!

We don't explicitly set the rules for issue titles and force ppl to follow.

Just suggest you can follow the same rule to write issue titles if you
ensure the involved [type] and [scope] like this example [1].
Otherwise, you can write as usual.

[1] https://github.com/apache/pulsar/issues/14928

Yu

On Thu, Aug 25, 2022 at 1:16 PM tison <wander4...@gmail.com> wrote:

> Anyway, it's a separate topic to discuss. If you want to discuss issue
> types and whether to label components, please start another thread.
>
> Best,
> tison.
>
>
> tison <wander4...@gmail.com> 于2022年8月25日周四 13:12写道:
>
> > From current issue templates, we already sort issues into bug reports,
> > improvements, doc changes, flaky tests, and PIPs. They're types. [type]
> and
> > [component] described here are applied to commit messages, not for
> issues.
> >
> > For components, we may encourage contributors to try their best to sort
> > out related components, but it's generally hard to do. I report a bug,
> how
> > can I know which components are related? It is required I have to dig it
> > out?
> >
> > Best,
> > tison.
> >
> >
> > tison <wander4...@gmail.com> 于2022年8月25日周四 13:08写道:
> >
> >> > Agree with applying the same rules ( [type] [scope] summary) for
> >> writing issue titles.
> >>
> >> It cannot be guarded by check so I think it only increases contributors'
> >> overhead.
> >>
> >> Instead, we can try to find out some integration if we can use the
> GitHub
> >> issue forms dropdown widget to allow contributors to tag the issue.
> >>
> >> I don't know whether it's possible, but it's better than setting up
> title
> >> rules. I can foresee that it's seldomly followed.
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> Liu Yu <li...@apache.org> 于2022年8月25日周四 12:59写道:
> >>
> >>> Thanks Max!
> >>>
> >>> Agree with applying the same rules ( [type] [scope] summary) for
> writing
> >>> issue titles.
> >>>
> >>> On 2022/08/25 02:48:51 Max Xu wrote:
> >>> > LGTM.
> >>> >
> >>> > And I think we should also update our issue templates.
> >>> >
> >>> > Best,
> >>> > Max Xu
> >>> >
> >>> >
> >>> > On Tue, Aug 23, 2022 at 6:04 PM Yu <li...@apache.org> wrote:
> >>> >
> >>> > > Hi team,
> >>> > >
> >>> > > Many thanks for your feedback! We've adjusted the convention based
> >>> on your
> >>> > > suggestions!
> >>> > >
> >>> > > Below is a brief summary of what we have reached a consensus on:
> >>> > >
> >>> > > ~~~~~~~~~~~~~~~~
> >>> > >
> >>> > > 1. Convention
> >>> > >
> >>> > > Continue to follow our existing convention (it's customized on
> >>> Agular) [1]
> >>> > >
> >>> > > ~~~~~~~~~~~~~~~~
> >>> > >
> >>> > > 2. Definition
> >>> > >
> >>> > > [type] must be one of the following:
> >>> > > - feat (abbr for "feature")
> >>> > > - improve
> >>> > > - fix
> >>> > > - cleanup
> >>> > > - refactor
> >>> > > - revert
> >>> > >
> >>> > > [scope] must be one of the following:
> >>> > > - admin
> >>> > > - broker
> >>> > > - cli (changes to CLI tools)
> >>> > > - io
> >>> > > - fn (abbr for "function")
> >>> > > - meta (abbr for "metadata")
> >>> > > - monitor
> >>> > > - proxy
> >>> > > - schema
> >>> > > - sec (abbr for "security")
> >>> > > - sql
> >>> > > - storage
> >>> > > - offload (changes to tiered storage)
> >>> > > - txn
> >>> > > - java
> >>> > > - cpp
> >>> > > - py
> >>> > > - ws (changes to WebSocket)
> >>> > > - test (changes to code tests)
> >>> > > - ci (changes to CI workflow)
> >>> > > - build (changes to dependencies, docker, build or release script)
> >>> > > - misc
> >>> > > - doc
> >>> > > - blog
> >>> > > - site
> >>> > >
> >>> > > For full details, see [Guide] Pulsar Pull Request Naming Convention
> >>> [2]
> >>> > >
> >>> > > ~~~~~~~~~~~~~~~~
> >>> > >
> >>> > > If you have any concerns, feel free to comment before 13:00 August
> >>> 25 (UTC
> >>> > > +8).
> >>> > >
> >>> > > We'll start implementing it if there is no objection after that
> time.
> >>> > >
> >>> > > Thank you!
> >>> > >
> >>> > > ~~~~~~~~~~~~~~~~
> >>> > >
> >>> > > [1]
> https://lists.apache.org/thread/90rcjf1dv0fbkb5hm31kmgr65fj0nfnn
> >>> > > [2]
> >>> > >
> >>> > >
> >>>
> https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit?pli=1#bookmark=id.y8943h392zno
> >>> > >
> >>> > > Yu and mangoGoForward
> >>> > >
> >>> > > On Tue, Aug 23, 2022 at 5:59 PM Yu <li...@apache.org> wrote:
> >>> > >
> >>> > > > Hi Jiuming, Yunze, tison,
> >>> > > > Thanks for your vote!
> >>> > > >
> >>> > > > ~~~~~~~~~~~~~~~~
> >>> > > >
> >>> > > > Hi tison,
> >>> > > >
> >>> > > > > "packaging logics"
> >>> > > > > For example, build the docker image, build & publish shell
> >>> scripts.
> >>> > > >
> >>> > > > If you refer to these changes, they belong to [build] scope.
> >>> > > >
> >>> > > > Yu and Zixuan
> >>> > > >
> >>> > > > On Tue, Aug 23, 2022 at 1:25 PM tison <wander4...@gmail.com>
> >>> wrote:
> >>> > > >
> >>> > > >> Hi Yu,
> >>> > > >>
> >>> > > >> Reply inline:
> >>> > > >>
> >>> > > >> > Besides, the existing scope, [tool], refers to Pulsar CLI
> tools
> >>> [1].
> >>> > > >> > We're considering to rename it to [cli] since:
> >>> > > >>
> >>> > > >> Make sense.
> >>> > > >>
> >>> > > >> > "deployment logic" If so, can we ignore this?
> >>> > > >>
> >>> > > >> I saw you already remove [deploy] scope. No comment here. It
> >>> should be
> >>> > > >> fine.
> >>> > > >>
> >>> > > >> > "packaging logics"
> >>> > > >>
> >>> > > >> For example, build the docker image, build & publish shell
> >>> scripts.
> >>> > > >>
> >>> > > >> >  How about defining [build] refer to the following?
> >>> > > >>
> >>> > > >> Make sense.
> >>> > > >>
> >>> > > >> > Two quick questions need your vote!
> >>> > > >>
> >>> > > >> To save letters, B & A.
> >>> > > >>
> >>> > > >> Best,
> >>> > > >> tison.
> >>> > > >>
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>
>

Reply via email to