Project Philosophy
FrankenTUI has an unusual contribution policy for an open-source project of its size: no outside PR merges. This page documents the policy in full, explains the reasoning, and sets expectations for what is and is not welcome.
If you’re here to file a bug, skip to bug reports are welcome. If you’re here to understand why, read the policy first.
The policy is not a moral position on contribution or an attack on the open-source ethos. It is a velocity decision. The author ships at a very high rate across many repositories; PR review at scale is the thing that would stop that. Everything downstream of the policy (agent-assisted triage, the bug-report welcome mat, the responsive issue handling) is designed to stay consistent with it.
The policy, verbatim
From the repository’s README.md:
About Contributions: Please don’t take this the wrong way, but I do not accept outside contributions for any of my projects. I simply don’t have the mental bandwidth to review anything, and it’s my name on the thing, so I’m responsible for any problems it causes; thus, the risk-reward is highly asymmetric from my perspective. I’d also have to worry about other “stakeholders,” which seems unwise for tools I mostly make for myself for free. Feel free to submit issues, and even PRs if you want to illustrate a proposed fix, but know I won’t merge them directly. Instead, I’ll have Claude or Codex review submissions via
ghand independently decide whether and how to address them. Bug reports in particular are welcome. Sorry if this offends, but I want to avoid wasted time and hurt feelings. I understand this isn’t in sync with the prevailing open-source ethos that seeks community contributions, but it’s the only way I can move at this velocity and keep my sanity.
Read it carefully. The policy is specific and consistent.
What the policy means in practice
PRs are not merged directly. An agent (Claude or Codex) reviews the
submission via gh, summarizes the change, and the author independently
decides whether and how to address it. If the fix is good, it may be
re-implemented in place. Your name stays on the issue; the commit is
the author’s.
The concrete shape of what happens when you file things:
| Contribution | Outcome |
|---|---|
| Bug report with a repro | Welcome. High-signal input. Often actioned fast. |
| Bug report without a repro | Welcome, but harder to action. Please include terminal, OS, and commit SHA. |
| Feature request | Welcome as discussion. May or may not be implemented. |
| PR that illustrates a proposed fix | Welcome as illustration. Not merged directly; the idea may be re-implemented. |
| PR that adds a new feature | Unlikely to be adopted. Not merged. The feature would need to match the project’s direction, and the re-implementation cost is usually higher than starting fresh. |
| Drive-by style / typo fix | Not merged, even when correct. The policy is uniform; there is no small-change exception. |
Why
Three reasons, stated plainly:
- Review bandwidth. The author maintains many repositories. Every PR review is time not spent shipping. At the velocity this project moves, even well-written PRs would pile up faster than they could be reviewed.
- Single-author correctness. The project is WIP. APIs change; the author wants to change them without coordinating with outside contributors whose work depends on them. Outside commits create stakeholders; stakeholders create constraints.
- Name-on-it liability. The author’s name is on the project. That means the author is responsible for breakage. A surprise bug introduced by a merged PR is still the author’s bug to fix. The risk / reward math isn’t symmetric.
None of this is about the quality of outside work. Plenty of the filed issues and PRs are excellent. They still don’t merge.
Bug reports are welcome
Bug reports are the high-signal contribution that the author actually wants. The welcome mat:
- File them freely. Issues on GitHub, ideally with a minimal repro.
- Include the commit SHA, terminal emulator, and OS.
- Paste the actual output (the corrupted terminal, the panic backtrace, the snapshot diff).
- Link to a gist or fork if the repro is nontrivial.
Even just “this demo screen crashes on my machine” is useful — it’s a lead the author can follow up on. Bug reports are not judged by language polish or length; they’re judged by whether they make the bug findable.
If you’re not sure whether something is a bug or a misconfiguration, file it anyway with a best-effort description. The cost of filing something that turns out to be a doc issue is smaller than the cost of not filing something that turns out to be a real bug.
What about security issues
Security issues: file privately via the repository’s security contact (see the GitHub repo’s Security tab) if you believe it is a real vulnerability. Public issues for security bugs are acceptable when the bug is already public or when the vendor has made coordinated disclosure difficult — but private-first is preferred.
What about feature discussion
Feature discussion happens in issues. Open an issue, describe what you want and why, link to concrete use cases. The author may or may not implement; if they do, the implementation shape will be the author’s choice.
Don’t ship a PR that implements your proposal and expect it to merge. It won’t. Even a well-implemented feature PR is not the accepted form of feature contribution.
What about forks
You are free to fork. The MIT + OpenAI/Anthropic Rider license explicitly allows it. If you maintain a long-running fork with outside contributions, that’s fine — it just isn’t upstream.
Acceptable fork uses:
- Private internal tooling built on FrankenTUI.
- Experimental extensions you want to prove out before proposing.
- Alternative widget libraries with different design goals.
Pitfalls
Don’t open a PR thinking you just need to make it small enough. The policy is uniform. A one-line typo fix is not merged either. File an issue instead; the typo will be fixed.
Don’t assume silence on a PR means it’s being reviewed. The most likely outcome is that an agent has summarized it, the author has read the summary, and the decision is “the underlying bug will be fixed independently.” Watch the issue tracker for the eventual fix commit.
Don’t be offended by the policy. It’s not personal. The author holds themselves to the same standard: no outside stakeholders, no velocity tax, clear single-author responsibility. It’s the only way the project moves at the rate it does.