Fork features ? also file upstream issues

Feature patched in repos/frk/ ? file upstream issue requesting same. If merged, drop patch

When I ask for a feature to be added to a fork (repos/frk/<slug>), do two things:

1. Patch it into our fork. Ship it now; we use it now.
2. File an issue upstream at the parent repo asking for the same feature. Polite, with the use-case clearly written. Link to the merged commit on our fork as a reference implementation.

Why both:

• We get the feature today regardless of upstream’s response.
• If upstream merges, we drop our patch on the next upstream sync and reduce maintenance burden.
• “No harm in asking” — upstream gets a feature request from a real user with working code attached.
• Future-proofs: if my preferences change, we edit/update the issue, not just our patch.

How to apply:

• Use gh issue create --repo <upstream-owner>/<upstream-repo> with a clear title + reproduction + rationale.
• Title pattern: feat: <feature-name> (with reference implementation linked).
• Include a link to our fork’s PR or commit so they can adopt the diff verbatim.
• Subscribe to the issue so we hear back. If upstream pushes back, capture the reasoning in our fork’s README so future me knows why we’re carrying the patch.

Permission note: I have standing authorization to file issues on any upstream of repos/frk/* without re-confirming each time. Same for editing/closing those issues later if my preferences change.

Related: fs-own-frk-split (forks live in repos/frk/), scope-cut-2026-06-25 (only patch features you actually ship today).

Edit on GitHub · Back to index