Investigate fork ratio: why are people forking but not opening issues?

[rajkumarsakthivel]

Research why the repo has forks but few issues or PRs, and suggest improvements.

Why: Forks without issues could mean: people are experimenting privately, the issue template is intimidating, or they hit problems but don't report them. Understanding this helps us lower the contribution barrier.

Steps:

1. Look at who forked (public info via GitHub API: `gh api repos/elara-labs/code-context-engine/forks`)
2. Check if forks have commits ahead of main (signals attempted contributions that weren't PR'd)
3. Review our issue templates and CONTRIBUTING.md for friction
4. Suggest 2-3 concrete changes to encourage issue/PR creation (e.g., simpler templates, a "feedback" issue form, discussion tab)

Deliverable: A short write-up (issue comment or doc) with findings and recommendations.

[suhalvemu]

Fork Ratio Investigation — Findings & Recommendations

What I looked at

• All 14 forks via the GitHub API — who forked, when, and how many commits ahead of `main` each one is
• The full `.github/` directory for issue templates and contribution infrastructure
• `CONTRIBUTING.md` for friction points that might discourage first-time contributors

---

What the data says

Repo health snapshot

Metric	Value
Stars	76
Forks	14
Open issues	13
Discussions	❌ Disabled
Issue templates	❌ None

The fork signal is actually good news

14 forks against 76 stars is an ~18% fork ratio — that's healthy. These aren't bots or mirrors; they're developers who cared enough to fork. The problem isn't interest — it's that interest has nowhere to go.

Every single fork is 0 commits ahead of `main`. Not one person pushed a change back. Most forks appeared in a 48-hour window (May 2–4), which points to a single discovery moment — likely a post or share that drove a wave of "I'll try this later" forks. A few forks (tradewithmeai, yashpatel1230) show pushes as recently as May 5, meaning someone is actively using the code — they're just not sending anything back.

That's the gap: people are using this, but there's no on-ramp for feedback.

What's blocking contribution

Three concrete gaps in the current setup:

1. No issue templates. .github/ISSUE_TEMPLATE/ doesn't exist. Clicking "New Issue" drops users into a blank text box with no guidance. This is one of the most well-documented drop-off points in open source — a blank box signals "this is for serious bug reports only," not "tell us what you think." Many people close the tab.

2. Discussions are disabled. There's no middle ground between silence and filing a formal issue. A lot of first-time feedback — "I tried it and wasn't sure how to configure X" or "this is cool, does it support Y?" — never gets filed because it doesn't feel issue-worthy. Discussions exist exactly for this.

3. CONTRIBUTING.md assumes you want to write code. It's a good document, but it starts at "fork the repo, clone it, set up a venv." There's no entry point for someone who just ran the tool and hit a problem or has a question.

---

Three changes that would move the needle

1. Add issue templates — this is the highest-leverage change

Create .github/ISSUE_TEMPLATE/ with two forms:

• bug_report.yml — structured fields: what happened, what you expected, steps to reproduce, Python version, OS. This makes filing a bug feel like filling out a form, not writing an essay.
• feedback.yml — 2–3 fields max: "What were you trying to do?", "Did it work?", "Anything confusing?" This is explicitly for the drive-by forker who ran the tool once and has thoughts.

GitHub's form-based issue templates are YAML and take about 20 minutes to set up. The payoff is significant — structured templates consistently increase issue volume on new repos because they remove the "I don't know what to write" blocker.

2. Enable GitHub Discussions

Settings → Features → Discussions. That's it.

This creates a space that feels conversational rather than bureaucratic. A question like "does this work with monorepos?" belongs in Discussions, not Issues — and right now there's nowhere for it to go, so it just doesn't get asked. Once Discussions is live, pin a "Welcome — tell us how you're using this" thread to seed engagement.

3. Add one line to the README after the quickstart

Tried it? Tell us how it went →

This hits users at the moment of highest engagement — right after they ran it for the first time. It doesn't require any new infrastructure, just a link to a pre-filled feedback issue or Discussions thread. Small ask, but it converts passive users into active ones by making the ask explicit.

---

Bottom line

The fork data doesn't show apathy — it shows a motivated audience with no clear path to engage. Nobody is silently building on top of this in private; they forked, ran it (or meant to), and then had no obvious next step. The fix is infrastructure, not outreach: issue templates, Discussions, and one explicit invite in the README. These are all low-effort, high-signal changes that compound over time as the repo grows.