mirror of https://github.com/Luchexx/wacrm.git synced 2026-11-02 09:19:51 +00:00

Arnas Donauskas 45574ec7ee

chore: reframe contributor docs fork-first

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>

2026-04-20 21:31:50 +03:00

4.4 KiB

Raw Blame History

Using WaCRM

WaCRM is a template repository, not a collaborative product. The expected flow is:

Fork it to your own GitHub account or organisation.
Deploy the fork — see docs/.
Customise your fork. Rebrand, add the features you need, remove the ones you don't, swap hosting, change the schema.

You don't need to send changes back upstream. The fact that your fork diverges is the whole point — the upstream is deliberately opinionated about stack, UX, and scope, and your fork is where those opinions become yours.

Fork and run

# 1. Fork on GitHub: https://github.com/ArnasDon/wacrm → Fork
# 2. Clone your fork
git clone https://github.com/<your-username>/wacrm.git
cd wacrm

cp .env.local.example .env.local   # fill in Supabase + Meta creds
npm install
npm run dev

Full setup (Supabase migrations, WhatsApp Business API, deploy) lives in docs/.

Keeping your fork up to date

Pull in upstream bug fixes and security patches periodically:

git remote add upstream https://github.com/ArnasDon/wacrm.git  # once
git fetch upstream
git checkout main
git merge upstream/main     # or: git rebase upstream/main
# Resolve any conflicts (likely in areas you've customised), then push
git push origin main

If you've made heavy local customisations, rebasing can surface conflicts every time you pull. Pinning to a specific upstream tag and updating on your schedule is a valid alternative.

Reporting bugs in the upstream template

If you find a bug in the upstream code — not one you introduced in your fork — please file it using the bug report template. Including the commit SHA, the runtime (Hostinger / Vercel / local / other), and logs will get to a fix fastest.

Reporting security issues

Do not file security issues publicly. Follow the private flow in SECURITY.md.

Upstream pull requests

Not the primary flow, but welcome in specific cases:

Security fixes — always welcome, please follow SECURITY.md first for disclosure.
Bug fixes that match upstream intent (crash, correctness, documentation errors, typos) — land quickly.
Small improvements (accessibility, obvious UX nits) — usually welcome, open an issue first to check alignment.

Less likely to land:

New features. The template's scope is intentionally narrow. A "great idea for a CRM" is often a great idea for your CRM — i.e. your fork — but would dilute the template for the next forker.
Stack changes (different ORM, different UI kit, different auth provider). These belong in a fork, not upstream.
Opinionated refactors without a concrete correctness or performance motivation.

If you do send a PR, the usual rules apply:

Branch off the latest main (don't push to a merged branch — commits end up orphaned).
Run npm run typecheck and npm run format locally first.
Fill in the PR template, especially the Test plan.
One logical change per PR.
Commit-message first line is imperative + terse; the body explains the why, the diff shows the what.

Expect a review within a few days. PRs opened without an issue may be closed — open the issue first to align.

If you maintain a public fork

Rebrand. The WaCRM name, favicon, and wacrm.tech URL belong to the upstream project; please swap them for your own before putting your deployment in front of users.
Keep the MIT LICENSE file — that's how the template's permissions travel with the code. Attribution in a README section is appreciated but not required.
You are free to re-license additions to your fork however you like.

Dev-loop reference

Even if you never send a PR upstream, these are the scripts you'll use in your fork:

Command	What it does
`npm run dev`	Turbopack dev server on port 3000.
`npm run build`	Production build. Next also runs its own typecheck here.
`npm run typecheck`	`tsc --noEmit`. Fast TS-only pass.
`npm run lint`	ESLint.
`npm run format`	Prettier write.
`npm run format:check`	Prettier in check-only mode. Useful in CI.

Licensing

This template is MIT (LICENSE). Anything you contribute upstream is assumed to be MIT too. Your fork's additions are yours to license however you like.

4.4 KiB Raw Blame History