Which backport PR labels should be added by the bot?
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 305
- Forks
- 148
- Avg merge
- 9h 2m
- Merged PRs (30d)
- 3
Description
Moving an interesting discussion ignited in https://github.com/nodejs/github-bot/issues/116 into its own issue.
Which labels should the bot automatically add when it attempts backport of PRs?
First a description of the current auto labelling logic, so we're all on the same page when discussing how backporting labels should work as a whole.
Backport attempt fails
PR patch does not land cleanly against a staging branch.
If it is a LTS staging branch dont-land-on-v${version}.x is added*, otherwise a previously added lts-watch-v${version}.x might be removed as long as the user added the watch label was the github-bot.
Backport attempt succeeds
PR patch lands cleanly against a staging branch.
If its a LTS staging branch lts-watch-v${version}.x is added, otherwise a previously added dont-land-on-v${version}.x is removed if the user who added the dont-label label was the github-bot.
Introduce explicit auto labels?
In https://github.com/nodejs/github-bot/issues/116 there were several questions and concerns related to the dont-land-on-* labels especially. Those labels are used by devs deciding what should go into staging branches, to definitely stop any unwanted PRs (described in https://github.com/nodejs/github-bot/pull/90#issuecomment-261095822 and https://github.com/nodejs/github-bot/issues/116#issuecomment-275544912). There has been raised concerns about those hard stop labels automatically, since the bot adding that label currently means it does not land cleanly, which it sounds is not the real intention of dont-land-on-* labels.
There has previously been suggested introducing explicit auto labels for these automatic backport attempts, such as auto-merge-to-v7.x-failed or similar as described in https://github.com/nodejs/github-bot/issues/116#issuecomment-275181198.
Who is these auto labels intended for?
In addition to exactly which labels the bot should add based on these backport attempts, it seems to be some confusion about who these labels are intended for. The PR author or devs staging for releases?
* dont-land-on-* labelling has recently been temporary disabled: https://github.com/nodejs/github-bot/pull/118
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the linked discussion in issue 116 and the label-related context in pull request 90 and pull request 118. Review the current success and failure labeling rules described here, then clarify which labels should be automatic and whether they serve PR authors or release-staging developers. Done requires an agreed labeling policy before implementation can be scoped.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, javascript
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100