Feature request: Option to move a PR from "open" to "draft"

[jakub-g]

Description:

Currently the stale action allows a 2-level workflow:

• after X days: mark as stale (+add comment, add label)
• after Y days: close the PR

It could be interesting to allow a 3-level workflow:

• after X days: move PR from "open" to "draft" (+optionally add comment)
• after Y days: mark as stale (+add comment, add label)
• after Z days: close the PR

Alternatively, if this sounds too complicated, an easier first step would be to "move to draft" as an subaction of marking as stale:

• after X days: mark as stale (optionally add comment, optionally add label, +optionally move to draft)
• after Y days: close the PR

Justification:

Personally I find marking PRs as "stale" and closing them as "this should only happen on very old PRs" (many months old). Whereas moving back to draft is "less dramatic".

• Draft PRs are a standard GH feature and have semantically different meaning and behavior.
  • For example, PR marked as draft can't be merged by accident.
• Marking PR as draft is leagues better than adding a label:
  • drafts are visually distinct from other PRs:
  • in PR detail view /pull/<n> (status icon in top-left of the PR)
  • in PR list /pulls, drafts have a different icon as well
  • drafts are searchable and can be excluded via a standard -is:draft query in GitHub searchbox, the query will be the same across all repositories.
  • For example one can find all review requests assigned to them on non-draft PRs via this query is:pr is:open user-review-requested:@me -is:draft
  • (To be fair, one could argue that the same can be achieved by -label:stale, although the label can be different in each repo, depending on the config).
• There are certain third-party integrations for the PRs which have an option to exclude draft PRs. For example GitHub-Slack integration which reminds about pending PR reviews.

Are you willing to submit a PR?

No

[HarithaVattikuti]

Hello @jakub-g Thank you for creating this feature request. We will investigate it and get back to you as soon as we have some feedback.

[mofosyne]

In addition it be good to combine this with some form of merge conflict detection to auto set to draft if older than X days with no activity and merge conflict has emerged or CI build is failing.

This is because just because a PR is old doesn't mean its outdated, but a merge conflict or failing CI is a pretty good indicator that more work is needed.

FYI you can lift code from here to get merge conflict detection https://github.com/eps1lon/actions-label-merge-conflict/blob/main/sources/main.ts

This is of interest so I can integrate these automation in a few community projects like llama.cpp