CI: Auto-label incoming pull requests

[krokoko]

Describe the feature

Add a GitHub Actions workflow that runs on incoming pull requests and automatically applies labels based on configurable rules (e.g. files changed, branch name, PR title, or draft status).

Examples of desired behavior:

• PRs that touch only docs/** get a label like documentation.
• PRs that add a new directory under plugins/ get the new-plugin label (required by MAINTAINERS_GUIDE).
• PRs that only change workflow files get a label like ci or workflows.
• Optionally: draft PRs get a draft label; or PRs from first-time contributors get a first-time-contributor label.

The exact rules can be decided during implementation, but the workflow should be the single place that performs automatic labeling so maintainers don’t have to remember to add labels manually.

Use Case

• Consistency: The maintainers guide says new-plugin PRs must have the new-plugin label. Today that’s manual; it’s easy to forget and then merge checks or triage can be wrong.
• Triage and filtering: Labels like documentation, ci, new-plugin help with filtering (e.g. “PRs needing review” by area) and with automation (e.g. routing, stale bot).
• Less manual work: Automatically applying obvious labels from changed paths or PR metadata reduces maintainer toil.

Proposed Solution

1. New workflow file

   • Add .github/workflows/label-pr.yml (or similar) that triggers on pull_request (opened, synchronize, or reopened) with contents: read and pull-requests: write (or issues: write if using issue labels) so it can add labels.

2. Labeling logic

   • Option A: Use an existing action (e.g. actions/labeler, dorny/pull-request-labeler) that supports path-based rules defined in a config file (e.g. .github/labeler.yml or .github/pr-labels.yml). Configure rules such as:
     • plugins/* (new or modified under plugins/) → new-plugin only when a new plugin directory is added (may require custom logic or a second action).
     • docs/** → documentation
     • .github/workflows/** → ci
   • Option B: A small composite or script step that uses the GitHub API (or gh pr edit) to add labels based on github.event.pull_request.changed_files or git diff and a small rule set.

3. Documentation

   • Document the workflow and the label rules in the repo (e.g. MAINTAINERS_GUIDE or a short section in DEVELOPMENT_GUIDE or a dedicated .github/labeler.md).

4. Safety

   • Prefer idempotent behavior (don’t fail the workflow if a label already exists). Avoid overwriting or removing labels that maintainers added manually unless that’s an explicit goal.

Other Information

• MAINTAINERS_GUIDE already requires the new-plugin label for PRs that add a new plugin directory; this workflow would enforce or assist that.
• If using a third-party action, prefer one that is maintained and has a clear license; pin by SHA for security.
• Consider whether to label only on pull_request.opened or also on synchronize so labels stay correct when the PR base or files change.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change