Documentation is not optional
When writing Tails code, one commits to adapt the design and end-user documentations accordingly in a timely manner, writing brand new chapters if needed.
As a side note, best is generally to write specification and design documentation before implementing changes; among other very valid reasons to do so, it may avoid doing work that won't be applied ever, or be reverted later, because of a faulty design that was reviewed and diagnosed only when the implementation was up and running. On the other hand, we're not great fans of over-engineering and we do know proceeding like this is not always an option, as the right design sometimes arises from erratic implementation attempts.
See our documentation guidelines.
Verify that your changes do not affect the rest of the user documentation and FAQ. If so, fix it in your development branch so that it gets automatically integrated when your branch get released.
Regarding the FAQ, don't write new questions in advance but make sure that the existing ones are still correct.
Test your code
A branch proposed for review and merge must have been tested when applied against the target branch(es) of the requested merge.
Do not break the build... or get reverted
Noone should ever push changes breaking the build into the shared Git
repository. On the other hand, this may happen since preliminary,
untested changes may in some circumstances land into our
branch to be reviewed and get more exposure.
If you find the
devel branch in a non-building state and can
identify the root cause of it to a recent commit, fix it if you wish,
but don't let it disturb you otherwise: just revert the faulty commit
and inform the other developers on email@example.com so that the author knows
s/he needs to fix his/her stuff before reapplying it at a later point.