bb acting too fast on no/wontfix

[wooorm]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions: n/a

Steps to reproduce

Close a PR. Write a comment. BB interferes too fast.

Expected behavior

10m delay?

Actual behavior

syntax-tree/unist-util-visit#23

[ChristianMurphy]

🤔 Maybe.
An alternative, would it make sense to recommend people post a comment before changing PR status?
BB's speediness/responsiveness is kinda nice.

[wooorm]

Generally it's fast, but in this case I envision the flow to be 1) label, 2) post human comment. Although i think your flow, the inverse, is working already!
The extra comment is more for maintainers forgetting, rather than for users. Although that could be changed. How do you see this flow?

[wooorm]

beep-boop-beta/tasks.yml

Line 130 in d904b1a

- if-not: recent-comment:team

Recent comment defaults to 1m; so if you comment first and then label within 30 seconds, bb won't comment

[ChristianMurphy]

I was thinking something along the lines of

                        +--------------+
                        |              |
                        | tag wont-fix |
                        |              |
                        ++------------++
                         |            |
   has no recent comment |            | otherwise
                         |            |
                         v            |
                  +-----------------+ |
                  |                 | |
                  |  BB add comment | |
                  |                 | |
                  +-+--------------++ |
                    |              |  |
maintainer comments |              |  |
                    |              | otherwise
                    v              |  |
       +------------------------+  |  |
       |                        |  |  |
       | BB removes own comment |  |  |
       |                        |  |  |
       +------------+-----------+  |  |
                    |              |  |
                    |              |  |
                    |              |  |
                    v              v  v
               +-------------------------+
               |                         |
               |          done           |
               |                         |
               +-------------------------+

[wooorm]

That’s almost the case:

beep-boop-beta/tasks.yml

Lines 128 to 133 in d904b1a

	- remove-labels:no/{duplicate,external,invalid,question}
	- sleep:30s
	- if-not: recent-comment:team
	then:
	- comment:no,no-wontfix
	- forget-comments:no

.
Except for the last step, bb removes own comment (as bb’s not yet user comments — and a maintainer can hide it for now manually)

[wooorm]

So I was thinking of upping it to 10m or so. You’re suggesting to remove the sleep completely?

[ChristianMurphy]

Except for the last step, bb removes own comment (as bb’s not yet user comments — and a maintainer can hide it for now manually)

BB hiding the comment could be a good alternative to removing it.

So I was thinking of upping it to 10m or so. You’re suggesting to remove the sleep completely?

Yes, that's my current thinking.

[wooorm]

BB hiding the comment could be a good alternative to removing it.

Hiding it isn‘t hard, but:
a) code to check comments is not written yet
b) running actions on every comment might be too much usage?
c) my flow is to typically label first and then explain in a comment if need be. Are you doing the inverse?

[ChristianMurphy]

my flow is to typically label first and then explain in a comment if need be. Are you doing the inverse?

I usually do this inverse, add a comment if need be, then tag.

running actions on every comment might be too much usage?

🤷‍♂️ Maybe.
Running for 10 minutes after a tag is added feels like it may be more intensive than a tasks that spins up, sees there's nothing to do, and spins back down. 🤔

[wooorm]

Running for 10 minutes after a tag is added feels like it may be more intensive than a tasks that spins up, sees there's nothing to do, and spins back down.

While true, I image the ratio of comments to labeled w/ no/wontfix to be 100 to 1.

---

Maybe this works, allowing both our flows, basically what you envisioned, but still using sleep:

- remove-labels:no/{duplicate,external,invalid,question} 
- comment:no,no-wontfix
- sleep:5m
- if: recent-comment:team 
  then:
    - minimize-comments:no
    - forget-comments:no 

Or even:

- remove-labels:no/{duplicate,external,invalid,question} 
- ifNot: recent-comment:team 
  - comment:no,no-wontfix
  - sleep:5m
  - if: recent-comment:team 
    then:
      - minimize-comments:no
      - forget-comments:no 

[ChristianMurphy]

While true, I image the ratio of comments to labeled w/ no/wontfix to be 100 to 1

Very possible,
that is potentially balanced out by the fact, that the job currently takes around 12 seconds, and a 10 minute wait would push it over 600 seconds, a ratio of around 50:1.
Running on comments would also allow BB to potentially respond to specific comments, similar to how https://github.com/typescript-bot does on definitely typed PRs.

[wooorm]

How would you feel about my last suggestion for now, and a new issue to discuss what comment flows would be useful?

[ChristianMurphy]

I'm open to it.
I wish there was a way to schedule another job, and shut down the process for the intermediate 5 minutes, but sleep may be one of the few options right now.