Proposal: Build a lightweight need-more-info logic with concise comments

#1

These days there are a number of contributors getting confused by ti-srebot labeling an issue by need-more-info and comment a long message; for example:

The original requirements is from quality assurance experts in our community, to collect information about type/bug issues of their fixed versions and affected versions.

However, the way is unclear to other contributors and one can hardly know whether the information is present unless he/she takes a closer look into the message and try to do a manual diff, i.e., to see if the “Affected versions” and “Fixed versions” section fulfilled.

It is apart from how GitHub manages issues; that is, using labels or milestone to sort out issues.

So, for the purposes on

  1. Reduce the confusion contributors meet.
  2. Keep the functionality quality assurance experts want, i.e., fixed versions and affected versions.
  3. Drop the use of ti-srebot which is deprecated and unmaintained.

I propose to build a lightweight need-more-info logic with concise comments.

I’m unsure whether labels or milestones are the better choice, but build a sample on labels as you can found on

https://github.com/tisonkun/actions-playground/issues/1

in this way, the implementation plan is

  1. Introduce “affects-{version}” and “fixed-{version}” labels, maybe we use from 2.0 to 5.2 and all patch versions.
  2. Introduce a GitHub Actions as in here.
  3. Remove current logic relying on ti-srebot.
1 Like
#2

Other projects

  • Perl uses “affects” labels to manage affected version, see also this page.
  • Flink use “affects version” and “fix version” with Jira, see also this page.

Reference

#3

After an offline discussion with @zhouqiang-cl and @jebter , we’d like to use affects-x.y and backport-x.y.z to label the issue.

See also the pull request