Enforce PR Templates

[rcaril]

Change summary

This PR adds a workflow that enforces PR templates for contributors outside of the fastly org.

The workflow does the following:

1. Checks new PRs from outside the org. When a non-draft PR from someone outside the fastly org is opened, edited, reopened or marked ready for review, it checks that the description includes a non-empty ### Change summary and the All Submissions: checklist.
2. Flags PRs that don't follow the template. If either part is missing, it adds the
   needs-template label and posts a single comment listing what to fix. When the description is fixed, the label and comment are removed.
3. Closes stale PRs daily. At 18:00 UTC, it closes any ready-for-review PR that has had the label for more than 3 days.
4. Skips internal and draft PRs. Org members (OWNER/MEMBER), bots and draft PRs are never checked. Converting a PR to draft clears the label, and the 3 days start again when it's marked ready for review.

Other notable Repos use similar workflows:

• electron/electron
• huggingface/trl

Both of these examples close non-compliant PRs immediately, while this proposed workflow provides a 3 day grace period.

Why

We have seen an increase in PRs that skip the template or include little context, which makes them slow to review. This check gives contributors early, consistent feedback on what we need, and closes PRs that don't provide it, so maintainers spend less time on back-and-forth.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

[rcaril]

This was an arbitrary time, we can change this to whenever makes sense to the team.

[rcaril]

I figured 3 days was ample time for a user to reply as well as allocates time for the weekend.

[rcaril]

I've already added this label.

[WhiteAbeLincoln]

Not blocking, but I wonder if we could compare the contents of .github/PULL_REQUEST_TEMPLATE.md instead of hardcoding regex strings? Pros: mostly repo-agnostic (we could maybe pull these actions out into our shared repository after they've been tested here), more stable under changes to the template. Cons: Might be harder to implement, maybe not performant if it requires a checkout on every trigger?

EDIT: It looks like this is the approach the electron repo uses.

[rcaril]

Not blocking, but I wonder if we could compare the contents of .github/PULL_REQUEST_TEMPLATE.md instead of hardcoding regex strings? Pros: mostly repo-agnostic (we could maybe pull these actions out into our shared repository after they've been tested here), more stable under changes to the template. Cons: Might be harder to implement, maybe not performant if it requires a checkout on every trigger?

I was considering this at first, but the issue is that the second half of the template is optional.

[WhiteAbeLincoln]

Not blocking, but I wonder if we could compare the contents of .github/PULL_REQUEST_TEMPLATE.md instead of hardcoding regex strings? Pros: mostly repo-agnostic (we could maybe pull these actions out into our shared repository after they've been tested here), more stable under changes to the template. Cons: Might be harder to implement, maybe not performant if it requires a checkout on every trigger?

I was considering this at first, but the issue is that the second half of the template is optional.

Yeah that does make it more difficult - we'd need a way to annotate sections as optional either in the template or as parameters in the action and then it's just getting too complicated. I'd say regex is probably fine for now, since we can always come back if we ever update the template and forget to update the action.

[anthony-gomez-fastly]

Do we want to have a step that removes the label if the check is satisfied? or do we want that to be a manual step that one of us takes

[rcaril]

Do we want to have a step that removes the label if the check is satisfied? or do we want that to be a manual step that one of us takes

Hmm, good question. My initial thought was that one of us should remove it, but i'm open to updating this pattern.

[anthony-gomez-fastly]

since the type is edited, we can check for edited description. I think it's reasonable to have it self remove if it gets fixed

[verythorough]

Thanks for doing this! I made a non-blocking suggestion in the doc.

I also wonder if we should adjust the opening statement to say that we're happy to receive contributions that solve actual user problems.

[verythorough]

I suggest reversing the order of these two.