mirror of
https://github.com/Luchexx/wacrm.git
synced 2026-11-02 17:29:45 +00:00
45574ec7ee
WaCRM is a template — users are expected to fork and customise their own deployment, not to send feature work back upstream. The previous CONTRIBUTING.md read like a standard collaborative-project onboarding guide and set the wrong expectation. Reframed docs: - CONTRIBUTING.md is now "Using WaCRM". Opens with "fork it and make it yours", covers forking + keeping-in-sync commands, explains which PRs do tend to land (security, correctness, docs, small nits) vs. which belong in a fork (new features, stack swaps, opinionated refactors). Keeps the filename so GitHub's built-in "Contributing guidelines" link still surfaces it. - .github/ISSUE_TEMPLATE/feature_request.yml: the intro block now tells the forker up front that feature requests usually become "build it in your fork", and describes the narrow cases where an upstream request is useful. - .github/ISSUE_TEMPLATE/config.yml: adds a third contact link pointing at CONTRIBUTING.md so people see the fork-first framing before filing. - .github/pull_request_template.md: prepends a heads-up that most changes belong in the forker's own repo, with a pointer to CONTRIBUTING.md. Nothing else in the PR changes — CoC, Dependabot, EditorConfig, Prettier configs, issue bug_report.yml, and the package.json changes are orthogonal to the fork-first framing and stay as-is. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
43 lines
1.3 KiB
Markdown
43 lines
1.3 KiB
Markdown
<!--
|
|
Heads up: WaCRM is a template, not a collaborative product. Most
|
|
changes belong in your fork. See CONTRIBUTING.md for which kinds of
|
|
upstream PRs tend to land (security, correctness, docs) vs. which
|
|
belong in a fork (new features, stack swaps, opinionated refactors).
|
|
If you haven't opened an issue yet for a non-trivial change, consider
|
|
doing that first to check alignment.
|
|
|
|
Keep this short and specific. The commit message is where the "why"
|
|
lives; this is where the reviewer gets the "what" and "how to try it".
|
|
-->
|
|
|
|
## Summary
|
|
|
|
<!-- One or two sentences. What does this PR do? -->
|
|
|
|
## What changed
|
|
|
|
<!-- Bullet list of the actual changes. Link file paths when useful. -->
|
|
|
|
## Test plan
|
|
|
|
<!--
|
|
How did you verify this works? How should the reviewer verify it?
|
|
Tick the boxes as you go.
|
|
-->
|
|
|
|
- [ ] `npm run typecheck` clean.
|
|
- [ ] `npm run lint` — no new errors beyond the pre-existing backlog.
|
|
- [ ] `npm run build` succeeds.
|
|
- [ ] Feature / fix manually exercised in the browser (or the reason it can't be).
|
|
|
|
## Related
|
|
|
|
<!-- Link the issue this closes, or "Part of #N" for multi-PR work. -->
|
|
|
|
<!--
|
|
Heads up:
|
|
- Security issues: do not disclose here; see .github/SECURITY.md.
|
|
- New deps: please justify briefly in the commit message or PR body.
|
|
- Runtime behaviour changes affecting forkers: update docs/*.
|
|
-->
|