This occurred in eslint/eslint#9524. I believe this might be because I added 4 labels simultaneously: enhancement, evaluating, rule, and needs info.

I'll go ahead and test this on this issue as well, by adding bug/needs info simultaneously (and then removing needs info, hopefully). If I'm right, this will generate 2 comments.

This issue says the commit message follows guidelines, but it doesn't: eslint/eslint#9768

I think the issue is that we don't look for a colon after the commit summary tag (Docs/Fix/Update, etc.).

Heya! 🎉 https://github.com/apps/triage-new-issues, hosted on https://triage-new-issues.now.sh
Just want to inform that i just created separate app for this and if you consider using it that would be great!

Very thanks to the @gyandeeps 🙏 for the code here. Let me now if there are some problems with the licensing and attribution, it is Apache 2.0 and have attribution comments to the @gyandeeps :)

In addition i also added issues.labeled listening, so when you add another than triage label(s) you don't need manually remove the triage label, bot will do that for you - just for saving UI clicking and time.

e.g. eslint/eslint#11018

I managed to regain control of our Dokku instance and would like to move the bot there. Doing so would allow us to do things like easily configure environment variables, which is needed for integrations with other services.

Example: We should be tweeting out whenever an RFC is opened or reaches final commenting period, but that hasn't happened because it's a manual process right now. With the ability to easily set environment variables, we can integrate with Twitter and automatically tweet out when this happens.

Any objections?

• GitHub: Change default branch name to main
• Update CI to use the correct branch to push to Dokku

People occasionally make PRs that just refactor code without modifying the intended functionality. In that case, there's no need for the PR to have tests.

Personally I think it might just be better to disable that plugin.

In the 2018-October-25 TSC Meeting we decided to auto-close old issues (with some caveats).

Note: this relates only to issues with an "accepted" label.

1. For issues with an assignee:

• At 30 days, at-mention the assignee and ask if they are still working on the issue
• At 90 days, at-mention the assignee and say that the issue now old and should either be completed or closed

2. For issues assigned to a project:

• At 30 days, at-mention the ESLint team and ask if anyone is working on the issue
• At 90 days, at-mention the ESLint team and say that the issue now old and should either be

3. For issues without an assignee AND without a project:

• At 30 days, assign the "help wanted" label and comment that the team is requesting help from the community to complete the issue.
• At 90 days, auto-close the issue with a message indicating that the issue is unlikely to be completed and is therefore closed (similar to the message I leave on old issues when I close them). Also, add an "auto close" label so we can easily track these.

I think checking for an assignee or milestone is a good way to make sure we don't close issues we find important, but definitely open to other suggestions.

I'd like to take a stab at implementing this because I've never worked in this repo before. :)

For the last 3 days or so, the bot has not been adding the triage label to new issues on the eslint/eslint repo. For example, see eslint/eslint#10440 and eslint/eslint#10444.

All of the webhook requests seem to be getting delivered successfully and returning 200 responses, so it seems like it's probably not an infrastructure problem.

A PR would likely be merged by accident, when it has not been accepted, while someone have approved.
We can add checking evaluating label to wip plugin(though it's not really wip). or another plugin?

Instead of leaving spammy comments and then deleting them when verifying peoples' commit messages, it would be nice if the bot left a status check on GitHub, with a link to a page explaining what's wrong.

Also related: eslint/eslint#8633

I was wondering if it might be worthwhile to augment the release-monitor plugin for breaking changes. Basically, it should create a failing or pending status check for breaking changes unless we know we're about to do a major release.

One possible approach:

1. Create a "major release pending" label that can be added to Release Issues when we are about to do a major release
2. Augment release-monitor to check for PRs with "Breaking:" in the merge commit message and create a failing/pending status check, unless there is a "major release" label on the release issue. Status check message would indicate that the change is breaking and that we cannot merge until we are doing a major release.

As we have more n more plugins, I have seen some need where some repos inside ESLint org may need to deactivate the behavior of a particular plugin and not make the plugin do something slightly different (this might be a rare case).

Proposal

• Start using settings files for eslint-bot, which is natively supported by Probot architecture.
• Introduce .github/eslint-bot.yml file which can store settings for each repo when needed.
• All the plugin can read these settings using the context.config function. Where a plugin also supply defaults for repos which do not have any settings.
• This feature can be used by plugins on a as needed bases. For example triage plugin needs no settings and it should be active for all repos always.

Current plugin usage

commit-message

• Default: On
• Add .github/eslint-bot.yml file inside eslint.github.io and tsc-meetings repo to disable this plugin.

release-monitor

• Default: Off
• Add .github/eslint-bot.yml file inside eslint repo to enable this plugin.

eslint-bot.yml

• Have object for each plugin out their and inside that object store different settings for that plugin.
• one common setting will be active with true or false value..

Test issue - DO not comment - feel free to unsubscribe

The commit-message plugin is rejecting "Revert " messages where the original commit is a merged PR, because it detects an issue/PR number that doesn't have fixes/refs before it.

Between that and the quotation marks around the message, it seems simplest to just say that any commit with "Revert " prefix should be considered valid.

Heya! Looks like this bot will do great job! :) But it would be cool to release that specific plugin as separate so anyone can use it :) I was thinking about such app/bot too.

It would be nice to have a plugin that would look at the current release issue, and leave a failing status check on all open PRs if we were in "semver-patch only mode". The goal would be to prevent us from accidentally merging semver-minor PRs while waiting for a patch release.

The bot would need a way to tell whether we're waiting for a patch release -- maybe a new label on the release issue?

When new commits are pushed to a PR, none of the existing statuses display on it anymore. If a PR is still WIP, the bot should probably reapply the status to the PR so that it keeps displaying that status.

Label name: fill issue template or issue template not filled or something similar

I have seen a few issues where the issue template was not filled. and some of them had no labels except for triage.
This is similar to how needs info works, when the label is added, it will show a comment with the direction.

In needs info it doesn't actually fill the content of the issue template. I guess it was designed for cases when even after the issue template the filled, there was some lack in info.

What this label will do is

• ask whether it is a bug or enhancement.
• ask the template question again accordingly.
• set the auto-close time for the issue to half than usual. i.e I guess 10 days
• and comment on why these are important.

Alternative

Add this information (⬆️) to the needs info comment itself.

As suggested here, this would allow people who follow the issue to also keep up with discussion that moves to a PR. This would probably work by having the bot listen for PRs that are created/edited to have an issue number in the title, and leave a comment on the corresponding issue.

We might also want to have some safeguard for preventing abuse if someone creates a PR with a title like #1 #2 #3 #4 #5 #6 #7 ... with the intent of having the bot create a bunch of spam comments.

When the bot creates an issue and adds a label to it at the same time, it occasionally adds the triage label to it as well. This happened on eslint/tsc-meetings#65, and it has also has happened inconsistently when I used a test instance of the bot on a private repository. (The bot adds a triage label whenever an issue is created and the payload of the issue event does not contain any labels already.)

This is happening because when an issue is created with labels, GitHub sends two webhook events: the first for creating the issue, and the second for adding a label. In some cases, the payload of the first webhook event includes the label. In other cases, the payload of the first event does not include the label. This seems like it might be a bug in GitHub's API, but I would need to investigate it further.

One temporary workaround would be to update the triage plugin to always prevent the bot from replying to its own issues. However, this would not be ideal because the same issue would occur if someone else was using the API to create an issue and add labels.

Currently, users are required to check their commit message from a failed commit message format check to our guidelines and manually figure out where the issue is. We should figure out a way to show a helpful message to the user when the commit message format check fails with either a helpful description in the status check or a comment on the PR. Example error messages:

• Missing tag
• Missing space after tag
• Too many characters

For example, if a user's PR title is too long, the status check could link to something like this:

https://eslint.org/commit-message-statuses?reason=too-long&type=pr-title

Then some JavaScript on that page would render a specific description of what the user needs to fix. This could make it easier for the user to figure out specifically what is wrong with their PR.

Very cool! A few things jumped out at me when liking through everything:

1. Maybe eslint-github-bot or eslint-repo-bot is a better name? eslint-bot sounds like it will run ESLint.

2. It would be helpful to stick with having a JSDoc comment at the top of each file describing what it does, as we do in other repos. It's not entirely clear from the rest of the file contents what's actually happening.

Otherwise, looks great!

Example issue: eslint/eslint#11188

When the auto-close plugin closes an issue, it usually leaves a message saying we couldn't muster enough support for the change (with slight variations if the issue is accepted or not accepted). I think if the issue has the "needs info" label, we should leave a different/shorter message saying the issue was closed because not enough information was provided.

When someone adds the needs info label, the bot's message is intentionally very generic, because we sometimes aren't sure what an issue is trying to do at all. However, there are other cases where the type of an issue is clear, but not enough information has been provided to respond to it (e.g. if the issue is proposing a new behavior but is insufficiently detailed about what the new behavior is). In these cases, the generic "needs info" message isn't as applicable.

It would be nice if the bot looked at the other labels on the issue, and gave a specialized message. For example, if enhancement, rule, and needs info were added at the same time, the bot would ask the user to fill out the rule change proposal template. If bug and needs info were added at the same time, the bot would ask the user to fill out the bug report template.

For example, eslint/eslint#9078 still has a pending status check because it is more than 30th on the list.

Though I'm not sure that it's possible.

As our guideline, accepting enhancement requires a champion and three or more 👍s.
But it's not easy to know the issue status because everyone can put 👍 icon.

So I think convenience if the bot adds labels which show the issue status.

1. About feature or enhancement issue.
2. The bot counts the number of 👍 of the team members, then the bot adds a label: 1-supported, 2-supported, 3-supported or something like.
3. The bot adds accepted label if there is an assignee and 3-supported.

How do you think?

atm it left a comment:

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.
Thanks for contributing to ESLint and we appreciate your understanding.

I think it could help set expectations better for issue authors if the auto-closer bot plugin could comment a few days before it auto-closes an issue (maybe 3 days before?) with a warning saying that the issue will be auto-closed due to inactivity and a link to our policy. It could potentially also add a label.

If someone else (non-bot) comments afterwards, the comment/label could be removed. Otherwise, 3 days later, the bot could auto-close as it does now.

Thoughts?

When creating a GitHub app, the app allows you to configure specific permissions on a repository. This bot probably doesn't need all of the permissions, so we should probably document the permissions that it does need.

I think it would be awesome to create a plugin which creates a pending status check whenever "do not merge" is added to a PR, and removes the status check when the label is removed.

I suggest "pending" instead of "failed" since in most cases, users might not be at fault. We can always add comments to the PR to indicate if a user needs to change something. But for the most part, implementation details don't matter to me.

Now that #96 has been merged, we can deploy the auto-closer plugin.

I don't want to do this at a random time, so opening an issue for the TSC discuss the timing of deploying this change.

Keep in mind that immediately upon deployment, a bunch of issues with end up being closed. If there is an issue that is of particular interest to you, then add yourself as an assignee (the bot skips over issues with assignees).

Feel free to deploy when I'm not around, I would just ask that an email be sent to the team mailing list ahead of time to let people know why there are mass issue closing. :)

Is there a particular reason why Travis only builds on the master branch (as configured in .travis.yml)? It's bad enough that I sometimes need to push branches to test something that doesn't fail locally; requiring a PR is just another level of pain 🙁

• When an issue with the release label is closed, the bot should check the date listed in the issue (either by parsing the issue text or by putting a marker in a comment in the issue body). Then it should create a new release issue scheduled for two weeks after the date of the previous release issue. The title and body of the new issue should contain the new date rather than the old date (this would probably be generated from a static template).
• We could do a similar thing for TSC meeting issues, except that rather than checking for release-labeled issues in the eslint/eslint repository, the bot would check for all issues in the eslint/tsc-meetings repository.
  • Optionally, the TSC meeting issue generator could also autogenerate the invite list based on the members of the @eslint/eslint-tsc team on GitHub, rather than hardcoding the list of TSC members.

Potential problems:

• If we make exceptions to the usual release schedule (e.g. if we do a release one week after the previous release rather than two weeks, due to special circumstances), then the release issue will be incorrect. I don't think this would be a big problem because we could just edit the incorrect issue to make it correct, and then the following issue would correctly be two weeks after the edited date. I think exceptions like this would generally be resolvable with O(1) issue edits by humans, as long as we don't change our usual release schedule to something other than once every 2 weeks.

• If we close a release issue, then reopen it, then close it again (like what happened in eslint/eslint#9220), the bot could generate a duplicate issue for the next release. There are a few possible solutions:

  • Since this is somewhat rare, we could just manually close the duplicate issue if it happens. (edit: this won't work because the bot would then create another issue for two weeks later.)
  • The bot could perform a search for other open issues with the release label, and avoid creating a new release issue if one already exists.
  • The bot could look at the event history of an issue to ensure that it only creates a new release issue the first time the old release issue is closed.

• If we start creating issues on the tsc-meetings repository for other purposes, or if other users create unrelated issues, then the bot could get confused and try to post a new TSC meeting issue when those unrelated issues are closed. One solution for this would be to start using the tsc-meeting label for all TSC meetings, and have the bot only respond to issues with that label.

I think we should update the readme to explain the general purpose of the bot in more detail. The Portal quotes at the top of the readme are amusing, but I don't think they give users a very good idea of what the bot does, especially since it's no longer called glados.

As discussed in the [2019/10/10 TSC meeting)(https://github.com/eslint/tsc-meetings/blob/63e51177ebcfdbaeaaa35f79d237b3f99cda3b04/notes/2019/2019-10-10.md), we agreed to move to a 4-week release cycle.

We should be able to change release-monitor to use a 4-week release cadence pretty easily.

See (e.g.) https://travis-ci.org/eslint/eslint-github-bot/builds/386991873.

In the issue-archiver unit tests, it looks like we are calling into real probot-scheduler code (possibly as a result of, or in combination with, calling bot.auth() unmocked in the test setup).

We need to look at a more robust mocking solution here. (When I tried looking at this, paginate proved difficult to mock out properly. It would be nice not to have to mock it out since all it does is invoke callbacks for the most part.)

Originally posted by @not-an-aardvark in #91

When a semver-patch PR is created during a post-release period, the bot adds a successful status check: `This change is semver-patch"

When a semver-patch PR (or any other PR) is created when there is no pending patch release, the bot adds a successful status check: "No patch release is pending"

When the post-release label is added to a release issue, a pending status check is added to all open semver-minor PRs. However, no status check is created for semver-patch PRs.

As a result, if a semver-patch PR is created when there is no pending patch release, and then the post-release label is added to a release issue, the status won't be modified, so the PR will incorrectly have the status "No patch release is pending".

To fix this, the bot should create a status check on all PRs when the post-release label is added to an issue. It should create the "A patch release is pending" status check for semver-minor PRs, and it should create the "This change is semver-patch" status check for semver-patch PRs.

On the 2019/10/10 TSC meeting, we agreed to change our release cadence to every 4 weeks. Some team members thought that 4 weeks might be too infrequent, but were willing to adopt the new schedule as long as we had a canary release option for users who want to live on the edge.

I'm marking this as accepted since the idea was originally conceived in a TSC meeting and voted on as part of a motion, but we'll want to review the design carefully before merging any PRs.

Now that we use issue templates with labels on the eslint/eslint repo, issues created by non-collaborators usually have labels added to them automatically. As a result, the bot no longer adds the triage label to them.

Is this desirable? I think it depends on the purpose of the triage label:

• If the purpose is to signal that a team member needs to investigate what type of issue it is in order to add the appropriate labels, then the triage label is mostly obsolete and the bot doesn't need to add it anymore.
• If the purpose is to signal that a team member should reply to an issue since it hasn't received a human response yet, then this is a bug and we should make sure to always add the triage label to issues created by non-collaborators.

I've noticed that we sometimes forget label pull requests, making it difficult to filter them to see whether they can be accepted. I think it would make sense for the bot to add the triage label to new pull requests (the same way that it adds the label for issues), as an indication that we need to update the labels.

Since we no longer enforce that commits end with "fixes [issue]" or "refs [issue]", we are now allowing commit messages which do mention an issue, but not the way we would like. (See eslint/eslint#9745 for an example.)

Would it be possible to flag commit messages that do contain "fixes [issue]" or "refs [issue]", but not formatted the way we like (i.e., in parentheses at the end of the commit summary)? Is this something we should consider doing?

Available plugins

• Triage - It add the triage label to the issues which doesn't have any labels.
• Commit message check - It checks the first commit message on PR and make sure it is formatted according to the guidelines. If not then it leaves a message on the PR.
• Duplicate comments - It removes all the duplicates comments by this bot and leaves the last one of each type. It uses a unique hash from the comment message.
• PR ready to merge* - Checks if the PR is ready to merge and if it is then it adds the pr: ready to merge label.
  • At least one review is approved.
  • Build status is success.
• Check unit test* - Make sure the PR contains unit test. This check will be ignored for Build|Chore|Docs|Upgrade PR title.
• More info - It adds the template for more info to the issue where the more info label is added.

Questions/Discussion

• Which of the available plugins needs to be disabled? (currently all of them are active)
• Any other plugins we need?

It looks like the bot is adding the auto closed label and commenting on issues that are already closed. See eslint/eslint#11859.

I'm unsure why this PR has a failing commit message check: eslint/eslint#12885

Wanted to record this for posterity in case this continues happening so we can look into it.

I think the "ready to merge" plugin has a few issues:

• It gets triggered by a single status check changing on a PR, even if there are multiple status checks. So if a status check fails, and then a different status check passes, it will add the label.
• It will respond to any approval review, even a review that isn't from a team member
• Also, the three concerns from #3 (comment)

Currently auto-close only closes issue, however, if the issue was created to just be a front for the PR, that leaves PR orphan and make it harder to track. Examples are here: eslint/eslint#11184 and eslint/eslint#11186