Actions: add Repo gardening action

[jeherve]

Changes proposed in this Pull Request:

This PR introduces a new action that will run on all issues and PRs in this repo.

More details about the action here:
https://github.com/Automattic/action-repo-gardening

The action is already used in the Calypso and Jetpack repos.

I've enabled 6 of the tasks the action offers so far:

1. Assign Issues (assignIssues): Adds assignee for issues which are being worked on, and adds the "In Progress" label.
2. Clean Labels (cleanLabels): Removes Status labels once a PR has been merged.
3. Flag OSS (flagOss): flags entries by external contributors, adds an "OSS Citizen" label to the PR, and sends a Slack message to the #themes channel.
4. Triage New Issues (triageNewIssues): Adds labels to new issues based on issue content. For this to work, I've also added a new "Bug Report" issue template, similar to the ones in use in the Calypso and the Jetpack repos, and that should help gathering information when issues are opened.
5. Gather support references (gatherSupportReferences): Adds a new comment with a list of all support references on the issue, and message in Slack when an issue starts getting a lot of tickets. More details about this in pcLjiI-Rb-p2 and pciE2j-1iy-p2
6. Reply to customers Reminder ( replyToCustomersReminder ): sends a Slack message about closed issues to remind Automatticians to update customers. Reference: pcLjiI-Ro-p2

What do you think about the changes?

I think we could start with those, and either add more or remove some of them in the future depending on how this first experiment goes.
I'm hoping this will help standardize some of the repo experience of both developers and HEs, with tools and automations that are similar in the different Automattic repos.

Here are a few screenshots of the tools in action in other repos; we cannot test this easily in this repo until this PR gets merged.

Internal reference: p1657879153257599-slack-C029FM1EH

[pbking]

Perhaps we should roll the mark stale action into the gardening action.

[jffng]

Thank you @jeherve !

I appreciate the effort to standardize our issue reporting and follow up across repos and teams. Some thoughts on each action added in this PR:

Assign Issues (assignIssues): Adds assignee for issues which are being worked on, and adds the "In Progress" label.

We use a project board for tracking issues in progress, so I think the In Progress label might be a bit redundant.

Clean Labels (cleanLabels): Removes Status labels once a PR has been merged.

What other status labels exist?

Flag OSS (flagOss): flags entries by external contributors, adds an "OSS Citizen" label to the PR, and sends a Slack message to the #themes channel.

👍

Triage New Issues (triageNewIssues): Adds labels to new issues based on issue content. For this to work, I've also added a new "Bug Report" issue template, similar to the ones in use in the Calypso and the Jetpack repos, and that should help gathering information when issues are opened.

Will the bug report template be used by default when creating a new issue, or can we still create issues that do not follow this template?

Gather support references (gatherSupportReferences): Adds a new comment with a list of all support references on the issue, and message in Slack when an issue starts getting a lot of tickets. More details about this in pcLjiI-Rb-p2 and pciE2j-1iy-p2

This seems very useful.

Reply to customers Reminder ( replyToCustomersReminder ): sends a Slack message about closed issues to remind Automatticians to update customers. Reference: pcLjiI-Ro-p2

There are existing mechanisms to follow up with customers built into platforms via zendesk and HC, so I'm wondering if this action will create more noise than anything.

[jeherve]

We use a project board for tracking issues in progress, so I think the In Progress label might be a bit redundant.

👍 I removed the task in 3b7944f

What other status labels exist?

For this repo, this would only apply to one status label: [Status] Needs Author Reply]

Will the bug report template be used by default when creating a new issue, or can we still create issues that do not follow this template?

It will not be used by default. Instead, you will be able to choose whether you want to use that template or open a blank issue (that blank issue will use your existing template: https://github.com/Automattic/themes/blob/bae583f0aaecacbefb2a9eb651aae90b8e9a13b4/.github/ISSUE_TEMPLATE.md )

You can see how issue forms look like in Jetpack, for example:
https://github.com/Automattic/jetpack/issues/new/choose

In this repo, and since this PR only offers to add one form, you would only get one option instead of 5.

There are existing mechanisms to follow up with customers built into platforms via zendesk and HC, so I'm wondering if this action will create more noise than anything.

I definitely don't want to add noise, so happy to remove it if it's not needed! Could you tell me more about your existing mechanisms? I could see if I could plug into that with our task / rely on them for other repos too. Feel free to ping me in Slack, I'll be happy to chat about this!

---

Perhaps we should roll the mark stale action into the gardening action.

That's a good point. Since it runs on a schedule and not on specific events, the 2 workflows are a bit different from one another. We would consequently need to add some logic to only run the gardening tasks when not on a scheduled run; I'm not sure that added logic is worth it, it may be cleaner to keep the 2 workflows separated for now, it would make them easier to understand and edit imo.

[jffng]

Could you tell me more about your existing mechanisms?

From my view, issues and PRs that affect customers directly typically fall into one of three categories:

1. Bug reports from HEs -> customers are notified by the reporter when the issue is closed.
2. Enhancements to new or existing themes
3. Larger coordinated efforts across teams, e.g. blockbase 3

My understanding is this is mostly relevant to the first case, is that correct? So with this action, does the person who opened the ticket get notified to reply to the customer when the issue is closed? And under what circumstances?

Since many issues do not fall into this category, I mainly want to ensure the use case is helpful to HEs, since they are most often the ones replying. For example, would we need to add a label like "Needs Customer Reply" for the issue author to get the ping?

[jeherve]

My understanding is this is mostly relevant to the first case, is that correct?

That's correct, it only impacts that first use-case.

So with this action, does the person who opened the ticket get notified to reply to the customer when the issue is closed? And under what circumstances?

The task will post a Slack reminder to notify customers, that will ping the WordPress.com Product Quality Squad in Happiness, under 3 conditions:

• The issue was just closed.
• The issue must have one of the following labels: [Pri] High , [Pri] BLOCKER.
• The issue must have at least a certain number of gathered support references (ZD tickets) that were added by HEs on the issue. By default, that number is 10, but we can change that.

This is triggered automatically, without the need to add a label manually.

This is mostly meant to ensure HEs can coordinate to send a bulk-reply to all impacted customers, on important issues where a lot of folks are impacted.
In practice, it hasn't been very noisy so far since, as you can imagine, most closed issues do not meet all the conditions.

Does that make sense?

[jffng]

Gotcha, that makes sense! Yeah I don't think many issues would meet all 3 criteria so that mitigates my concern about noisy notifications.

Let's try it out.