build and the tests should pass after each commit. Changes to lib,
cli, emacs, tests, man pages, or news are usually best kept
separate. Also separate cleanups from functional changes. See the
-Notmuch source history (`git log`) for examples.
+Notmuch source history (**`git log`**) for examples.
For in-depth discussion on the subject, see
[Software Release Practice HOWTO](http://tldp.org/HOWTO/Software-Release-Practice-HOWTO/) by Eric S. Raymond.
on commit guidelines, including commit messages.
It is customary to prefix the subject line with "lib:", "cli:", "emacs:",
-etc. depending on which part of Notmuch the commit is changing. See `git log`
-for examples.
+etc. depending on which part of Notmuch the commit is changing. See
+**`git log`** for examples.
Wrap the lines to about 72 characters.
If you make user visible changes, you should add an entry to the
[`NEWS`](http://git.notmuchmail.org/git/notmuch/blob/HEAD:/NEWS) file.
+## Update command-line completion
+
+If you modify or add new features to the Notmuch command-line tools, it
+would be a nice bonus if you also updated the Notmuch command-line
+completion scripts under the `completion` directory of the Notmuch
+source. Not required, but nice to have, and definitely can be done
+afterwards.
+
## Subscribe to the Notmuch mailing list
While strictly not required, it is advisable to subscribe to the
Even better, send a patch adding a "known broken" test to the test suite
highlighting the issue.
+## Update the Notmuch website
+
+Update the Notmuch website, especially if you've landed a commit that
+changes or obsoletes information on the site. It's a wiki; see the
+[[instructions on how to edit the wiki|wikiwriteaccess]].
+
## Join the Notmuch IRC channel
Patch review happens on the Notmuch mailing list, but there is plenty of