Contributing¶

How to get a change from your machine into the project, and what we expect of it along the way.

Before you start¶

To write: what to do before writing code — where to check that the work is not already underway, and when to raise something for discussion first rather than arriving with a finished branch.

Where changes go¶

To write: which repository takes which kind of change, and which branch to target. Our trees are forks with their own branch conventions, so say plainly where a contributor should aim.

Commits¶

To write: the commit conventions we hold to — message format, granularity, and sign-off if we require one.

Sending a change¶

To write: the mechanics of opening a change for review, and what to include in the description. Say what evidence is expected for a change that claims a hardware result — this ties back to Testing.

Review¶

To write: who reviews, what reviewers look for, and roughly how long it takes. Being honest here saves contributors from guessing.

Licensing¶

To write: the licence contributions are made under, and what a contributor is asserting when they submit. Cover what to do when carrying code in from another project — see Attribution for how we credit upstream work.

Conduct¶

To write: a short pointer to Policies & Guidelines rather than restating it here.