]> git.cworth.org Git - notmuch-wiki/blobdiff - contributing.mdwn
new file: news/release-0.21.mdwn
[notmuch-wiki] / contributing.mdwn
index 1c8bd5bdd266650a3b3c5fbb403c74101fa969d5..c92853fd90b9108d97c033edcf07217eae4d7bbf 100644 (file)
@@ -9,7 +9,8 @@ but once you get the hang of it, it'll be fun. This page should help
 you get there. DON'T PANIC.
 
 The headlines below act as a checklist. Not all of them apply in all
-situations; use common sense.
+situations. Use your best judgment, and the Notmuch community will
+help out as needed.
 
 [[!toc levels=2]]
 
@@ -58,7 +59,7 @@ Each commit should contain one logical change only. The code should
 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.
@@ -74,8 +75,8 @@ See also
 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.
 
@@ -105,7 +106,7 @@ in the Notmuch source for further information.
 ## Update the documentation
 
 If you modify or add new features to the Notmuch command-line tools,
-you should update the manual pages under the `man` directory of the
+you should update the manual pages under the `doc` directory of the
 Notmuch source.
 
 If you modify or add new features to the Notmuch Emacs UI, you should
@@ -116,6 +117,14 @@ update the Emacs documentation.
 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
@@ -160,7 +169,7 @@ like email. This applies to patch and bug tracking as well. The
 Notmuch project uses [nmbug](http://notmuchmail.org/nmbug/) for
 tracking. The Notmuch developers will tag your patches too, making
 them show up in the
-[nmbug status page](http://nmbug.tethera.net/status/), but requesting
+[nmbug status page](http://nmbug.notmuchmail.org/status/), but requesting
 access and tagging your patches yourself will be helpful in the long
 run.
 
@@ -182,14 +191,13 @@ have changed; be sure to rebase your updated changes on top of the
 current master.
 
 Once you have the updated series ready, send it to the mailing list
-again. It will be helpful for others to use the
-`--subject-prefix="PATCH vN"` option of `git format-patch` or
-`git send-email` to add a version number of the patch series to the
-subject (replacing vN with v2, v3, etc.) Use a cover letter (or, in
-the case of a single patch, the notes after a "---" at the end of the
-commit message) to summarize the main changes since the previous
-version of the patch series. Also include the message-id reference of
-the previous version.
+again. It will be helpful for others to use the `-vN` option of `git
+format-patch` or `git send-email` to add a version number of the patch
+series to the subject (replacing vN with v2, v3, etc.) Use a cover
+letter (or, in the case of a single patch, the notes after a "---" at
+the end of the commit message) to summarize the main changes since the
+previous version of the patch series. Also include the message-id
+reference of the previous version.
 
 Using the `--in-reply-to` option of `git format-patch` or
 `git send-email` to send the patch series as a reply to the earlier
@@ -214,6 +222,12 @@ subject line with "BUG:" or similar. Tag the message as a bug in
 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