From 2099920ccaad2f174c86bd152031f0e7117005a1 Mon Sep 17 00:00:00 2001 From: 4444J99 <4444J99@users.noreply.github.com> Date: Wed, 1 Jul 2026 08:26:42 -0400 Subject: [PATCH] Simplify `CONTRIBUTING.md` to standard PR workflows limen task GH-organvm-dot-github-logos-18 --- CONTRIBUTING.md | 71 ++++++++++++----------------------- QUICK_START.md | 22 +++++------ docs/activation-audit-2026.md | 2 +- 3 files changed, 34 insertions(+), 61 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2aa556e..454e2ed 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,59 +1,36 @@ # Contributing -Thanks for your interest in contributing! This organization publishes essays, -process documentation, and methodology writing, along with the automation that -supports them. Contributions of all sizes are welcome — typo fixes, docs, bug -fixes, and new ideas. +Thanks for your interest in contributing. This repository contains organization +profile and community health files, including shared documentation, templates, +and policy files. By participating, you agree to follow our [Code of Conduct](CODE_OF_CONDUCT.md). ## Ways to contribute -- **Report a bug or suggest an idea** — open an [issue](../../issues). For - anything large (a new essay topic, a change to the publishing workflow, an - editorial policy update), open an issue to discuss it before writing code. -- **Pick up existing work** — issues labeled `good first issue` are a great - starting point. -- **Open a pull request** — see the workflow below. -- **Report a security vulnerability** — please follow [SECURITY.md](SECURITY.md) - instead of opening a public issue. +- Report a bug or suggest an improvement by opening an [issue](../../issues). +- Fix a typo, update documentation, or improve a template with a pull request. +- For larger changes, open an issue first so maintainers can discuss the + direction before you spend time on implementation. +- To report a security vulnerability, follow [SECURITY.md](SECURITY.md) instead + of opening a public issue. ## 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. + +## Questions + +If you are not sure where to start, open an [issue](../../issues) with your +question or ask on the pull request. *Part of the [organvm system](https://github.com/meta-organvm).* diff --git a/QUICK_START.md b/QUICK_START.md index eb46144..8e7d9c4 100644 --- a/QUICK_START.md +++ b/QUICK_START.md @@ -73,13 +73,9 @@ README — it is authoritative if it differs from the above. ### Code / automation repos `essay-pipeline`, `analytics-engine`, and `reading-observatory` are code -repositories. Per the [contribution standards](CONTRIBUTING.md) they use: - -- **TypeScript** — strict mode, named exports, `async/await` -- **Python** — PEP 8, type hints, f-strings - -After installing dependencies, run the repo's test command (listed in its -README) to confirm a working local setup before making changes. +repositories. Use each repo's `README` as the source of truth for setup, style, +and checks. After installing dependencies, run the test or lint command listed +there before making changes. --- @@ -88,20 +84,20 @@ README) to confirm a working local setup before making changes. Once you can run things locally: 1. Pick an issue labeled **`good first issue`**. -2. Confirm scope, validation commands, and acceptance criteria before coding. -3. Fork → branch (`feature/your-feature` or `fix/your-fix`) → keep changes focused. +2. Fork the repo and create a branch from `main`. +3. Make a focused change. 4. Run the repo's local validation commands. -5. Open a PR with a clear description. +5. Open a pull request with a clear description. -Full details — accepted change types, review SLAs, development standards — are in -**[CONTRIBUTING.md](CONTRIBUTING.md)**. +See **[CONTRIBUTING.md](CONTRIBUTING.md)** for the standard pull request +workflow. --- ## Where to go next - **[Organization profile](profile/README.md)** — what ORGAN-V is and how it fits the eight-organ system -- **[CONTRIBUTING.md](CONTRIBUTING.md)** — full contribution workflow and standards +- **[CONTRIBUTING.md](CONTRIBUTING.md)** — contribution workflow - **[CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md)** — community expectations - **[SECURITY.md](SECURITY.md)** — reporting vulnerabilities - **[README standards](README_STANDARDS.md)** — README structure each repo follows diff --git a/docs/activation-audit-2026.md b/docs/activation-audit-2026.md index accab20..ffdccca 100644 --- a/docs/activation-audit-2026.md +++ b/docs/activation-audit-2026.md @@ -44,7 +44,7 @@ real?** | --- | --- | --- | | `profile/README.md` | LIVE | Org-profile surface; substantive, renders publicly | | `README.md` | LIVE | Repo landing; links the governance assets | -| `CONTRIBUTING.md` | LIVE | Standard fork → branch → PR workflow, 59 lines | +| `CONTRIBUTING.md` | LIVE | Standard fork → branch → PR workflow | | `CODE_OF_CONDUCT.md` | LIVE | 78 lines | | `SECURITY.md` | LIVE | Advisory + email path, response timeline | | `QUICK_START.md` | LIVE | Newcomer entry point, linked from both READMEs |