X-Git-Url: https://git.notmuchmail.org/git?p=notmuch-wiki;a=blobdiff_plain;f=contributing.mdwn;h=34b7eb6e7b48785de64884b93abc27b38d7d1bcf;hp=cc0d90911c26bcddd25cca352c7d70e9982d0999;hb=HEAD;hpb=dd42cd3de55662fc683a9069fff4d1ec3cb7a1d5

diff --git a/contributing.mdwn b/contributing.mdwn
index cc0d909..a5bbfb3 100644
--- a/contributing.mdwn
+++ b/contributing.mdwn
@@ -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]]
 
@@ -18,7 +19,7 @@ situations; use common sense.
 The Notmuch source code is maintained in [git](http://git-scm.com/). Get the
 source code using:
 
-	git clone git://notmuchmail.org/git/notmuch
+        git clone https://git.notmuchmail.org/git/notmuch
 
 This guide assumes a working knowledge of git. There are plenty of resources
 available on git, such as [Pro Git](http://git-scm.com/book) and the git man
@@ -30,11 +31,11 @@ The changes you submit should almost always be based on the current
 Notmuch git master. There are plenty of ways to work in git, and this
 is not your git guide, but a typical workflow might start with:
 
-	git fetch origin
-	git checkout -b my-local-branch origin/master
-	# make changes
-	git add ...
-	git commit
+        git fetch origin
+        git checkout -b my-local-branch origin/master
+        # make changes
+        git add ...
+        git commit
 
 If you're planning big changes, it may be advisable to __not__ polish
 the patch series according to all the details described below at
@@ -48,7 +49,7 @@ achieve. You may prefix the subjects of such patches with "RFC" or
 
 The Notmuch code base follows a fairly uniform coding style. See the existing
 code around your changes, and read
-[`devel/STYLE`](http://git.notmuchmail.org/git/notmuch/blob/HEAD:/devel/STYLE)
+[`devel/STYLE`](https://git.notmuchmail.org/git/notmuch/blob/HEAD:/devel/STYLE)
 in the Notmuch source. It's not difficult to get it right, and may save you an
 extra review round.
 
@@ -99,45 +100,59 @@ easy to confirm your changes actually fix the issue. Some people use this
 approach also for adding new features.
 
 See
-[`test/README`](http://git.notmuchmail.org/git/notmuch/blob/HEAD:/test/README)
+[`test/README`](https://git.notmuchmail.org/git/notmuch/blob/HEAD:/test/README)
 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
 update the Emacs documentation.
 
+If you add a new keybinding, update `devel/emacs-keybindings.org`. As
+much as possible, try to be consistent between modes.
+
 ## Update NEWS
 
 If you make user visible changes, you should add an entry to the
-[`NEWS`](http://git.notmuchmail.org/git/notmuch/blob/HEAD:/NEWS) file.
+[`NEWS`](https://git.notmuchmail.org/git/notmuch/blob/HEAD:/NEWS) file.
+
+In practice adding NEWS items can be done later during the release
+process, but then you typically get a one line mention, if at all.
+
+## 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
-[Notmuch mailing list](http://notmuchmail.org/mailman/listinfo/notmuch)
+[Notmuch mailing list](https://nmbug.notmuchmail.org/list/)
 before submitting patches.
 
 ## Send your patches to the mailing list
 
 Changes to Notmuch are contributed as [emailed
-patches](http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Public-Large-Project).
+patches](http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Public-Project-over-Email).
 Once you have your changes ready in your local repository, you need to
 send them to the Notmuch mailing list. The simplest way is to use `git
 send-email` to send the patches directly from your repository:
 
-	git send-email --to notmuch@notmuchmail.org origin/master
+        git send-email --to notmuch@notmuchmail.org origin/master
 
 An alternative is to do this in two steps; first generating patch
 files (using `git format-patch`), and then sending the patch files to
 the mailing list (using `git send-email` or a mail client):
 
-	git format-patch origin/master
-	git send-email --to notmuch@notmuchmail.org *.patch
+        git format-patch origin/master
+        git send-email --to notmuch@notmuchmail.org *.patch
 
 Either way, using `git send-email` to actually send the patches is
 recommended. It may be distributed separately from git, typically in a
@@ -149,7 +164,7 @@ If you are submitting a non-trivial set of patches, or if there's any
 extra information you want to share that is not really part of the
 commit messages, it is advisable to write a cover letter to give an
 overview of your work. See the
-[Notmuch mailing list archives](http://notmuchmail.org/pipermail/notmuch/)
+[Notmuch mailing list archives](https://nmbug.notmuchmail.org/nmweb/)
 for examples. Use the `--cover-letter` option of `git format-patch`,
 or `--compose` option of `git send-email`.
 
@@ -157,10 +172,10 @@ or `--compose` option of `git send-email`.
 
 When you're developing an email tool, all the problems start looking
 like email. This applies to patch and bug tracking as well. The
-Notmuch project uses [nmbug](http://notmuchmail.org/nmbug/) for
+Notmuch project uses [nmbug](https://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](https://nmbug.notmuchmail.org/status/), but requesting
 access and tagging your patches yourself will be helpful in the long
 run.
 
@@ -171,7 +186,7 @@ usually by one or two developers, depending on the impact of the
 changes. You are expected to follow up on the review comments you
 receive, either by discussing the comments and the code, or modifying
 your patches. Again, see the [Notmuch mailing list
-archives](http://notmuchmail.org/pipermail/notmuch/) for examples.
+archives](https://nmbug.notmuchmail.org/nmweb) for examples.
 
 ## Send another round addressing review comments
 
@@ -182,14 +197,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
@@ -197,7 +211,7 @@ version is generally discouraged, particularly for large series, but
 there are no hard rules. Usually the message-id reference to the
 previous version is sufficient and preferred.
 
-Tag the old patches obsolete in [nmbug](http://notmuchmail.org/nmbug/)
+Tag the old patches obsolete in [nmbug](https://notmuchmail.org/nmbug/)
 if you have access.
 
 ## Review other people's work
@@ -209,14 +223,20 @@ people to review your patches if you review theirs.
 
 Send bug reports to the Notmuch mailing list. Preferably prefix the
 subject line with "BUG:" or similar. Tag the message as a bug in
-[nmbug](http://notmuchmail.org/nmbug/).
+[nmbug](https://notmuchmail.org/nmbug/).
 
 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
-discussion going on in the freenode #notmuch IRC channel. See
-[freenode.net/irc_servers.shtml](http://freenode.net/irc_servers.shtml)
+discussion going on in the libera #notmuch IRC channel. See
+[libera.chat/guides/connect](https://libera.chat/guides/connect)
 for information how to get there.