docs(community): soften contributor requirements

.github/ISSUE_TEMPLATE/bug-report.yml

@@ -7,7 +7,8 @@ body:
   - type: markdown
     attributes:
       value: |
-        Thanks for reporting this. Keep the report concrete and reproducible.
+        Thanks for reporting this. Use as much of this template as you can.
+        A partial but useful report is better than no report.
   - type: dropdown
     id: area
     attributes:
@@ -20,8 +21,6 @@ body:
         - Provider integration
         - Install or packaging
         - Documentation
-    validations:
-      required: true
   - type: textarea
     id: summary
     attributes:
@@ -34,33 +33,25 @@ body:
     id: reproduction
     attributes:
       label: Reproduction steps
-      description: Exact steps, commands, inputs, and settings needed to reproduce.
+      description: Exact steps are ideal, but rough steps are still helpful.
       placeholder: |
         1. Run `ccs ...`
         2. Open ...
         3. Observe ...
-    validations:
-      required: true
   - type: textarea
     id: expected
     attributes:
       label: Expected behavior
-    validations:
-      required: true
   - type: textarea
     id: actual
     attributes:
       label: Actual behavior
-    validations:
-      required: true
   - type: input
     id: version
     attributes:
       label: CCS version
-      description: Output of `ccs --version`
+      description: Output of `ccs --version`, if you have it
       placeholder: 7.54.0
-    validations:
-      required: true
   - type: dropdown
     id: os
     attributes:
@@ -70,8 +61,6 @@ body:
         - Linux
         - Windows
         - Other
-    validations:
-      required: true
   - type: textarea
     id: environment
     attributes:
@@ -94,8 +83,5 @@ body:
       label: Before submitting
       options:
         - label: I searched existing issues first.
-          required: true
         - label: I removed secrets and private data from logs/screenshots.
-          required: true
         - label: I can still reproduce this on the latest released or dev build.
-          required: false

.github/ISSUE_TEMPLATE/documentation.yml

@@ -4,6 +4,10 @@ title: "docs: "
 labels:
   - documentation
 body:
+  - type: markdown
+    attributes:
+      value: |
+        Small or rough documentation reports are welcome. You do not need to fill every field.
   - type: dropdown
     id: area
     attributes:
@@ -15,8 +19,6 @@ body:
         - Command help output
         - Dashboard copy or labels
         - Other
-    validations:
-      required: true
   - type: input
     id: location
     attributes:
@@ -41,4 +43,3 @@ body:
       label: Before submitting
       options:
         - label: I checked whether this is already covered elsewhere in the repo.
-          required: true

.github/ISSUE_TEMPLATE/feature-request.yml

@@ -8,6 +8,7 @@ body:
     attributes:
       value: |
         Feature requests land faster when they describe the user problem first and stay narrow.
+        Rough ideas are still welcome if they are grounded in a real workflow or pain point.
   - type: dropdown
     id: area
     attributes:
@@ -20,8 +21,6 @@ body:
         - Install or packaging
         - Documentation
         - Contributor workflow
-    validations:
-      required: true
   - type: textarea
     id: problem
     attributes:
@@ -32,10 +31,8 @@ body:
   - type: textarea
     id: proposal
     attributes:
-      label: Proposed solution
+      label: Proposed solution or direction
       placeholder: Add a command or dashboard control that ...
-    validations:
-      required: true
   - type: textarea
     id: user-flow
     attributes:
@@ -64,6 +61,4 @@ body:
       label: Before submitting
       options:
         - label: I searched existing issues and discussions first.
-          required: true
         - label: This request describes a concrete user problem, not just a broad idea dump.
-          required: true

.github/pull_request_template.md

@@ -4,6 +4,8 @@
 
 ## Testing
 
+Use what applies. If you skipped something, add a short note instead of forcing it.
+
 - [ ] `bun run validate`
 - [ ] `bun run validate:ci-parity`
 - [ ] `cd ui && bun run validate` if UI changed
@@ -11,6 +13,8 @@
 
 ## Checklist
 
+Check what applies. Not every item is relevant for every PR.
+
 - [ ] Base branch is `dev` unless this is an approved hotfix
 - [ ] Branch name follows `feat/*`, `fix/*`, `docs/*`, or approved hotfix naming
 - [ ] Relevant `--help` output updated if CLI behavior changed

CONTRIBUTING.md

@@ -4,7 +4,7 @@ CCS is a Bun + TypeScript CLI with a React dashboard. This guide is the shortest
 
 ## Before You Start
 
-- Open or claim an issue if the change is more than a typo.
+- An issue is helpful for medium or large changes, but small fixes and docs updates can go straight to a PR.
 - Branch from `dev`.
 - Open PRs against `dev`.
 - Use conventional commits.
@@ -116,7 +116,7 @@ Use `bun run dev` from the repo root when working on the local dashboard experie
 
 ## Validation
 
-Run these before you open or update a PR:
+If you can, run these before you open or update a PR:
 
 ```bash
 bun run format
@@ -144,6 +144,8 @@ bun run test:e2e
 
 `bun run validate` is the main gate. It covers typechecking, linting, format checks, maintainability checks, and automated tests for the main project.
 
+If you cannot run the full suite, that is still fine for early or docs-only PRs. Just say what you did run, or what blocked you, in the PR.
+
 ## What To Update With Your Change
 
 ### If you change CLI behavior
@@ -165,7 +167,7 @@ bun run test:e2e
 
 ## Commit Style
 
-All commits must use conventional commit format.
+CCS uses conventional commits because the release and workflow tooling depend on them.
 
 ```bash
 git commit -m "fix(doctor): handle missing config gracefully"