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>
69 lines
2.3 KiB
YAML
69 lines
2.3 KiB
YAML
name: Feature request
|
|
description: Propose a new feature or a meaningful enhancement.
|
|
title: "[feat] "
|
|
labels: ["enhancement", "triage"]
|
|
body:
|
|
- type: markdown
|
|
attributes:
|
|
value: |
|
|
Thanks for the idea — but read this first.
|
|
|
|
WaCRM is a **template**, not a collaborative product. The
|
|
upstream scope is intentionally narrow, so most feature
|
|
requests end up as *"build this in your fork"* rather than
|
|
landing here. That's the point of a template.
|
|
|
|
When an upstream feature request *is* useful:
|
|
|
|
- It fixes a correctness problem in the template.
|
|
- It makes the template cleaner for the next forker (reducing
|
|
friction, removing footguns).
|
|
- It's in scope for "a generic WhatsApp CRM template" rather
|
|
than a bet on your specific workflow.
|
|
|
|
If the feature is really for your own deployment, fork and
|
|
build it there — see
|
|
[CONTRIBUTING.md](https://github.com/ArnasDon/wacrm/blob/main/CONTRIBUTING.md).
|
|
|
|
- type: textarea
|
|
id: problem
|
|
attributes:
|
|
label: What's the problem?
|
|
description: What are you trying to do today that WaCRM makes harder than it should?
|
|
placeholder: |
|
|
When a broadcast ends I have no way to see which recipients
|
|
didn't reply so I can follow up manually.
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: proposal
|
|
attributes:
|
|
label: What would you like to see?
|
|
description: Describe the feature from the user's perspective, not the implementation.
|
|
placeholder: |
|
|
On the broadcast detail page, a "No reply" filter that lists
|
|
recipients who received but didn't reply within 24 hours.
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: alternatives
|
|
attributes:
|
|
label: Alternatives you considered
|
|
description: Things that kinda work today, workarounds, related features in other tools.
|
|
validations:
|
|
required: false
|
|
|
|
- type: dropdown
|
|
id: scope
|
|
attributes:
|
|
label: Scope
|
|
description: Your guess — we'll re-scope if needed.
|
|
options:
|
|
- Small (a couple of hours)
|
|
- Medium (a couple of days)
|
|
- Large (a couple of weeks, probably breaks into multiple PRs)
|
|
validations:
|
|
required: false
|