Record external contribution lineage without overstating rights or value
This tutorial follows the pattern already demonstrated by Vector #26501 / PR #26504 and Memnox #46 / PR #86: an external problem becomes a BTG contribution, the exact change-set is recorded, upstream independently reviews/accepts it, and economic state remains separate from technical acceptance.
1. Capture the external problem before changing code
Record the upstream repository, issue number, issue state, problem statement, licensing context, maintainer/assignment state and any explicit bounty or sponsorship terms.
2. Create the smallest defensible change-set
Work against a pinned upstream base. Record the exact files changed, tests added/changed, local validation limits, commit SHA and branch. Do not claim that ENTITY owns upstream project code merely because it records the contribution.
3. Validate locally, then let upstream remain independent
- Run the relevant tests and negative cases.
- Record local limitations honestly.
- Push the exact contribution commit.
- Open the upstream pull request.
- Preserve maintainer review, CI and requested changes as external evidence rather than rewriting them as BTG-controlled validation.
4. Record ENTITY lineage by phase
A practical external-contribution state progression is:
For each phase preserve predecessor receipt/hash, repository and issue identifiers, exact commit/head SHA, changed paths, evidence references, contribution class and economic state.
5. Only record upstream acceptance after it actually happens
Acceptance evidence should use live upstream facts: PR merged/accepted state, final PR head, accepted upstream commit/tree where available, maintainer review, CI/check results and issue closure where applicable.
Vector and Memnox demonstrate this boundary publicly. Their accepted contribution records are externally anchored because unrelated upstream projects merged the work.
6. Preserve the accepted source/recovery evidence where needed
For a stronger evidence campaign, snapshot the accepted tracked source and prove it can be recovered from governed BTDU state without relying on the original working directory or network. The qualified Memnox case recovered all 865 tracked blobs plus its archive, manifest and acceptance evidence.
7. Record economic state separately
| State | Meaning |
|---|---|
| PRO_BONO / USD 0 | The contribution was accepted without a paid settlement claim. |
| PROMISED / CONTINGENT | Compensation terms may exist but are not yet settled. |
| FUNDED / SETTLED | Only use after the relevant economic obligation and settlement evidence actually exist. |
| Contribution-value evidence | Upstream acceptance can evidence technical adoption; it does not itself assign a monetary valuation. |
8. Publish only the evidence needed for public verification
The public ledger can expose contribution identity, upstream state, review/CI status, exact accepted head/commit, licence context and explicit economic state while keeping sensitive keys/private workspace material out of the publication layer.
9. Success criteria
- The contribution can be traced from external issue to exact submitted code.
- Independent upstream review/CI is distinguishable from BTG-controlled validation.
- Final acceptance is tied to immutable upstream identifiers.
- Licence/rights context is preserved.
- Economic settlement is only claimed when separately evidenced.
- The public record is sufficient to verify the claim without exposing private keys.