Contributing to someone else’s repository

Contribution Requests are Rinko Hub's equivalent of pull requests. They are how you offer work to a repository you do not have write access to: the owner enables contributions, you record a version of your change, and you submit it with a structured declaration of what it does and how you tested it.

Why the model differs

That is the last time this page uses the older vocabulary, because the mechanism underneath is genuinely different and the analogy stops being useful immediately. Nothing is copied: there is no second repository, no personal copy, and therefore no second history to reconcile later. What you get instead is one workspace inside the one repository, derived for your account from the repository's accepted state and pinned to the exact version it was derived from. There is no per-contributor branch, and the repository's own branches stay closed to you. Each submission records an immutable revision — a content-addressed version id that cannot be rewritten after a reviewer has read it — and when a maintainer accepts one, it becomes a candidate of the repository's target workspace: a version competing to become the accepted state, sitting beside whatever else is competing, rather than a change applied on top of a moving target. That is why this documentation has no word for "upstream": there is one repository, and you are working in part of it.

Join the contribution area

Joining registers you as a contributor and creates the workspace your work will live in. It publishes nothing and offers nothing for review — it is the step that gives you somewhere to work.

On the web, open the repository and choose Join contribution area. From the command line, one command registers you and brings the work in as a working context under your Development Root:

$ nexa contribute owner/repository

Like nexa get, this command names the repository rather than inferring it from the directory you are standing in, so it takes no project selector. It registers first and creates the directory second: if registration is refused, your Development Root is left exactly as it was, with nothing half-created. --as <DIRECTORY> chooses a different directory name. Both routes are the same act — joining on the web and then running nexa contribute is fine, and re-running it does not create a second workspace, because the workspace name is derived from your account rather than chosen.

How your contribution workspace works

The workspace is an ordinary Nexa workspace with three properties worth knowing before you start:

Working in it is ordinary Nexa work. Edit files, then record and synchronize:

$ nexa record -m "Fix the parser on empty input"

$ nexa sync

nexa sync moves your recorded versions into your own contribution workspace and brings the repository's accepted state back to you. It cannot move anything else: a synchronization that named a workspace outside your scope is refused as a whole rather than partly applied, so a partial success can never look like a completed submission. Your own local workspaces are simply not offered, and nothing fails because of them.

Submit a Contribution Request

Submitting takes the version your contribution workspace currently selects and offers it as a Contribution Request, together with a structured declaration of what the change is.

$ nexa contribution submit --title "Fix the parser on empty input"

--title opens a new request. The rest of the declaration is optional but is what a reviewer reads first: what the change does (--summary), why it is worth making (--why), what kind of change it is (--type, repeatable), which areas it touches (--area), what it affects (--impact), and how you tested it:

$ nexa contribution submit --title "Fix the parser" --type bug_fix --tested yes --test unit:passed:28:0

--report <FILE> supplies the whole declaration as JSON, and explicit flags amend it rather than being ignored. The web form at Contributions → New asks for exactly the same fields, so the two routes produce the same record. The full flag table is in the CLI reference.

Three refusals happen on your own machine, before anything is sent: the directory is not a contribution workspace, your working tree holds edits the recorded version does not include, or nothing has been recorded at all. The second one is deliberate and is never quietly worked around — a reviewer reading a version that does not match the tree you were looking at is the exact failure it prevents.

Revisions

A Contribution Request holds a numbered sequence of immutable revisions. Nothing you submit is ever edited; a change to your proposal is a new revision, and the old one stays readable exactly as it was reviewed.

$ nexa contribution submit --to 42

--to <NUMBER> submits a new revision of the request with that number. Giving both --to and --title is refused: a request that exists already has a title.

What a testing declaration means

Everything in your declaration is self-reported, and it travels marked as such: every testing method you state is recorded with selfReported: true, permanently and everywhere it is read. It is your account of what you did.

A check is a different kind of statement: a result written by a check provider the repository configured, about one specific revision. The two are never merged and are never rendered as though they were the same thing. Declaring that your tests passed does not produce a passing check, and the repository's maintainers see both, labelled.

Be accurate rather than generous. --tested partially is a real and common answer, and a reviewer can act on it; an inaccurate yes is discovered by the person reading your change.

What happens to your request

A Contribution Request moves through a fixed set of states:

You can withdraw your own request from any state that is still open, and you can always read and comment on it. You can never approve your own work. The four end states are final: there is no reopening, and a contribution you still believe in is submitted again as a new request — which keeps the closed one honest about what was decided and when.

Accepted is not integrated. Acceptance makes your exact reviewed version a candidate of the repository's target workspace — a version competing to become its state. A separate, explicit maintainer action selects or merges it. Your request records both, so you can tell which has happened.

nexa contribution status reports all of this from the command line: your eligibility, your workspace, its pinned base version, whether the version you currently select has already been submitted, and every request you have open.

When contributions are unavailable

Two refusals are worded precisely, and they are not interchangeable.

This is about you, on this repository only. It deliberately says nothing about why: distinguishing one reason from another would make the message an oracle for a decision you are not entitled to read. It is repository-scoped — it says nothing about your account anywhere else on Rinko Hub. Work you already submitted is not deleted, and the workspace itself is not destroyed; what stops is your ability to submit or revise here.

This is about the repository, is identical for everyone, and is therefore no oracle at all. The owner has either never enabled contributions or has turned them off. Turning them off deletes nothing: existing requests stay where they are, and whether maintainers may still review and accept them is the repository's own choice.

If you are a member of the repository with write access already, you do not need the contribution area at all — you have a shorter path to the same outcome, and Rinko Hub offers that instead.