Guide new SEP proposals towards discussions first#1949
Conversation
…sions When a PR adds a new file under ecosystem/, it is likely proposing a new SEP. This workflow locks the PR and comments explaining that new ideas should start as a GitHub Discussion, be collaborated on by the ecosystem, and only then be merged by a maintainer who assigns the SEP number. Includes a reminder to never pre-allocate SEP numbers.
…ions Reference the canonical SEP process docs in ecosystem/README.md using anchored links (Contribution Process, Pre-SEP discussion, Creating a SEP Draft, SEP Status Terms), and point at the correct org-level GitHub Discussions category for SEPs.
|
Thank you for clarifying this. |
There was a problem hiding this comment.
Pull request overview
Adds a GitHub Actions workflow to automatically detect PRs that introduce new Markdown files under ecosystem/ (likely new SEP drafts), then post guidance pointing authors to the discussion-first SEP process and lock the PR conversation to reinforce that flow.
Changes:
- Introduces a new
pull_request_targetworkflow scoped to changes underecosystem/**. - Uses
actions/github-scriptto list PR files via the API, detect newly added SEP-like Markdown files, and post a process-guidance comment. - Locks the PR conversation after commenting to steer collaboration toward GitHub Discussions.
| pull_request_target: | ||
| types: [opened, reopened] | ||
| paths: | ||
| - 'ecosystem/**' |
| await github.rest.issues.createComment({ | ||
| owner, | ||
| repo, | ||
| issue_number: pull_number, | ||
| body, | ||
| }); | ||
|
|
||
| await github.rest.issues.lock({ | ||
| owner, | ||
| repo, | ||
| issue_number: pull_number, | ||
| lock_reason: 'resolved', | ||
| }); | ||
|
|
||
| core.info(`Locked PR #${pull_number} and posted the SEP proposal guidance.`); |
| permissions: | ||
| issues: write | ||
| pull-requests: write | ||
|
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9d0b0bece0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| pull_request_target: | ||
| types: [opened, reopened] | ||
| paths: | ||
| - 'ecosystem/**' |
There was a problem hiding this comment.
Include synchronize events for added SEP files
With only opened and reopened, this workflow misses the common case where a contributor opens a PR that does not initially touch ecosystem/, then pushes a commit adding ecosystem/sep-xxxx.md; paths would match that later diff, but the workflow is not subscribed to the synchronize activity, so no guidance comment or lock is applied. Include synchronize if the intent is to catch a new SEP at the moment it is added to an existing PR.
Useful? React with 👍 / 👎.
Skip commenting and locking when guidance has already been posted (detected via a hidden marker in the comment body), so reopened PRs are not re-commented or re-locked and a maintainer's deliberate unlock is respected. Reduce the pull-requests token scope to read since listing changed files needs only read access and locking/commenting go through the issues API.
What
Add a GitHub Actions workflow that steers new SEP proposals toward the discussion-first process the moment a pull request adds a new file under the
ecosystem/directory. It greets the author with a comment that points them to the org's GitHub Discussions as the right place to socialize the idea, links into the relevantecosystem/README.mdsections (Contribution Process, Pre-SEP discussion, Creating a SEP Draft, and SEP Status Terms), and reminds them to leave the SEP number unassigned since a maintainer assigns it on merge. The PR is locked until the proposal has been collaborated on and the author requests a merge in their discussion.Why
New contributors sometimes open a pull request as the first step of proposing a SEP. Contributors sometimes self-assign a SEP number either to their discussion or their PR. The documented process expects ideas to be socialised and collaborated on in the org's GitHub Discussions before an idea is formalised and merged. Guiding authors to discussions first, automatically and consistently, means every new-SEP PR gets an immediate pointer to the correct process and the canonical status documentation without a maintainer having to repeat it by hand. Immediate feedback allows the contributor to act immediately while they are still engaged, rather than having that longer feedback cycle. The workflow uses
pull_request_targetso the token can comment and lock even on fork PRs, and it only inspects the changed-file list rather than checking out or running any PR code.Generated by Claude Code