Skip to content

chore(ionitron): remove 'awaiting reply' on comment from issues#3046

Merged
rwaskiewicz merged 5 commits intomasterfrom
rwaskiewicz/ionitron-dont-close-issues-prematurely
Sep 3, 2021
Merged

chore(ionitron): remove 'awaiting reply' on comment from issues#3046
rwaskiewicz merged 5 commits intomasterfrom
rwaskiewicz/ionitron-dont-close-issues-prematurely

Conversation

@rwaskiewicz
Copy link
Copy Markdown
Member

this PR is the first step in trying to improve our automation in GitHub.
it removes the 'Awaiting Reply' label and replaces it with the 'Reply
Received' label when an individual replies to a GitHub issue via a
comment.

this PR also prevents issues that are tagged with 'Reply Received' from
being culled by the stale issue configuration.

this is a first step in improving our workflow. this PR does not cover
every possibility/scenario for interacting with the community.

this PR is the first step in trying to improve our automation in GitHub.
it removes the 'Awaiting Reply' label and replaces it with the 'Reply
Received' label when an individual replies to a GitHub issue via a
comment.

this PR also prevents issues that are tagged with 'Reply Received' from
being culled by the stale issue configuration.

this is a first step in improving our workflow. this PR does not cover
every possibility/scenario for interacting with the community.
@rwaskiewicz rwaskiewicz requested review from a team and kensodemann September 3, 2021 13:17
Copy link
Copy Markdown
Contributor

@kensodemann kensodemann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I would probably either remove stale or bump the days to something more like 180 or something.

30 seems a little obnoxious, and was originally set that way because Adam's plan was to stay on top of the issues, and anything that sat for 30 days after initial triage without being assigned to someone was not likely to get addressed.

Clearly, though, it eventually reached a state where nothing simply got addressed.

@rwaskiewicz
Copy link
Copy Markdown
Member Author

Thanks! I'm 100% amenable to bumping the number of days. I'll bring this up after standup this morning and see if we can come to consensus as a team what number we prefer

Copy link
Copy Markdown
Contributor

@splitinfinities splitinfinities left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No blockers, looks great and thank you SO much for improving this behavior!

- help wanted
- good first issue
- help wanted
- Reply Received
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good signal!

lock: true
dryRun: false

noReply:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what exactly is this block doing? I can gather a lot from the config. But does this help inform the other tasks that will do things like closing after x days?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When a comment is received on an issue, if the issue has the label: Awaiting Reply, we remove said label and apply the responseLabel: Reply Received (because we set dryRun: false, the changes in labels will actually happen).

We set lock: false and close: false as a safety precaution - this action shouldn't close and/or lock an issue, because that'd be super frustrating. Imagine replying to the Stencil team (probably after doing some work to help us understand an issue), only to get your issue tagged with 'Reply Received' and then locked & closed.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest adding a "days" and a "message" to maybe give add a reminder message after X days without a reply (let's say 30).

If you leave "close" and "lock" false, this should just ping them a message in the sweep without swapping the label, but swap the label if someone else replies.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We set lock: false and close: false as a safety precaution - this action shouldn't close and/or lock an issue, because that'd be super frustrating. Imagine replying to the Stencil team (probably after doing some work to help us understand an issue), only to get your issue tagged with 'Reply Received' and then locked & closed.

In reality, it should only do a close or lock if you have days set, but since I suggest having days set with a message, then if you do not want the close and lock then yeah, have those false.

FWIW, I think the Framework at least does the close if no one responds. A close without a lock with a message like the FW uses may be appropriate as well. 🤷‍♂️

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The FW only gives ppl 14 days to respond. Seems short to me, but hey... They also close AND lock. I would probably just to with close and no lock to give the person a chance to respond if they forgot about it or whatever, and then let the "stale" task do the lock after a much longer period.

https://github.com/ionic-team/ionic-framework/blob/main/.github/ionic-issue-bot.yml#L100-L116

@splitinfinities
Copy link
Copy Markdown
Contributor

I'm also in favor of 180 days FWIW.

lock: false
message: >
Hey there! Just a friendly reminder that the Stencil team would like some additional
input on this issue. Thanks!
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One VERY pedantic thing: "Thanks" in text can be read as passive aggressive more easily than "Thank you!" - could we reword this to "Thank you!"?

@rwaskiewicz rwaskiewicz merged commit 231d857 into master Sep 3, 2021
@rwaskiewicz rwaskiewicz deleted the rwaskiewicz/ionitron-dont-close-issues-prematurely branch September 3, 2021 17:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants