[limen GH-organvm-dot-github-logos-18] Simplify CONTRIBUTING.md to standard PR workflows#37
[limen GH-organvm-dot-github-logos-18] Simplify CONTRIBUTING.md to standard PR workflows#374444J99 wants to merge 1 commit into
CONTRIBUTING.md to standard PR workflows#37Conversation
limen task GH-organvm-dot-github-logos-18
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2099920cca
ℹ️ 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".
| Thanks for your interest in contributing. This repository contains organization | ||
| profile and community health files, including shared documentation, templates, | ||
| and policy files. |
There was a problem hiding this comment.
Because this .github repo publishes community-health defaults to sibling repositories that do not define their own CONTRIBUTING.md (the activation audit documents that fallback), this new repo-specific description will also appear in those repos and incorrectly tells contributors to projects like public-process or essay-pipeline that the repository contains only org profile/community-health files. Please make this introduction organization-wide or repository-neutral so the default guidance remains accurate when GitHub reuses it across the org.
Useful? React with 👍 / 👎.
| ## Pull request workflow | ||
|
|
||
| 1. **Fork** the repository and create a branch from `main`. | ||
| 2. **Make your change.** Match the style of the surrounding code or prose, and | ||
| keep the change focused — smaller PRs are easier to review and merge. | ||
| 3. **Run the repo's checks** (tests, lint, build) if it has them. Each repo's | ||
| `README` lists its setup and validation commands. | ||
| 4. **Open a pull request** with a clear description of what changed and why. | ||
| Link any related issue. | ||
|
|
||
| A maintainer will review and may suggest changes before merging. We aim to give | ||
| an initial response within a few business days; please be patient if it takes a | ||
| little longer. | ||
|
|
||
| ## Style guidelines | ||
|
|
||
| These are conventions, not gates — follow them where they apply, and ask if | ||
| you're unsure. | ||
|
|
||
| - **Commits** — write clear messages in the imperative mood ("Fix typo in | ||
| intro"), with a title under ~72 characters. | ||
| - **TypeScript** — strict mode, named exports, `async/await`. | ||
| - **Python** — PEP 8, type hints, f-strings. | ||
| - **READMEs** — follow the [README standards](README_STANDARDS.md). | ||
| - **Essays** — include the YAML frontmatter described in the publishing guide | ||
| (title, author, date, tags, category, excerpt, and the other fields listed | ||
| there). | ||
| - **Tests** — if you change code that has tests, please keep them passing and | ||
| add coverage for new behavior. | ||
|
|
||
| ## Getting help | ||
|
|
||
| - Open an [issue](../../issues) with any question. | ||
| - Check the relevant repo's `README` — it's the source of truth for that repo's | ||
| setup and workflow. | ||
|
|
||
| --- | ||
| 1. Fork the repository and create a branch from `main`. | ||
| 2. Make a focused change. Keep pull requests small when possible. | ||
| 3. Run any relevant checks listed in the `README`. If there are no checks, or | ||
| you could not run them, note that in the pull request. | ||
| 4. Open a pull request with a clear description of what changed and why. Link | ||
| any related issue. | ||
| 5. Respond to review comments if maintainers request changes. | ||
|
|
||
| Maintainers will review pull requests as time allows. Once a pull request is | ||
| approved and any required checks pass, a maintainer will merge it. |
There was a problem hiding this comment.
SECURITY.md still directs contributors to “follow secure coding practices per CONTRIBUTING.md”, but this rewrite removes the only standards/style section from CONTRIBUTING.md, and a repo-wide search shows no remaining secure-coding guidance there. In security-sensitive changes, that cross-reference now lands on a generic PR workflow instead of the practices it promises, so either keep a minimal secure-coding/standards section here or update the security policy to point at the actual source.
Useful? React with 👍 / 👎.
|
Owner-blocked during estate merge/reap on 2026-07-09. This PR has successful checks, but it is not safely mergeable after the current default-branch drain: Next command: rebase or merge current |
|
Engagement disposition: superseded by current main. I verified the core contribution-guidelines intent is now shipped: CONTRIBUTING.md is a short standard workflow (ways to contribute, pull request workflow, style guidelines, help path), and QUICK_START.md points first contributors to good-first-issue work. This PR is now CONFLICTING/DIRTY despite a green validate check, so it should not be merged unless the author identifies a distinct remaining contribution-policy delta beyond the current main files. |
4444J99
added
the
lifecycle:blocked
1 participant
Autonomous limen dispatch of task
GH-organvm-dot-github-logos-18.GitHub issue #18. Participants felt the contribution guidelines were too strict or used non-standard terminology. We should align it with standard open-source workflows.
Refs: #18
Produced in an isolated worktree off origin — review before merge.