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