docs: proofread and fixes

A slew of proofreading fixes to documentation.

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>

10 files changed, 159 insertions, 104 deletions

diff --git a/docs/config.rst b/docs/config.rst
index a95e1a9..68e0dd4 100644
--- a/docs/config.rst
+++ b/docs/config.rst
@@ -12,16 +12,25 @@ Since the purpose of b4 is to work with git repositories, this allows
 the usual fall-through configuration that can be overridden by more
 local settings on the repository level.
 
-.. note:: Per-project defaults
+Per-project defaults
+~~~~~~~~~~~~~~~~~~~~
+.. note::
+
+   This feature is new in v0.10.
 
-   A project may ship their own b4 config with some defaults, placed in
-   the toplevel of the git tree. If you're not sure where a
-   configuration option is coming from, check if there is a
-   ``.b4-config`` file in the repository you're currently using.
+A project may ship their own b4 config with some defaults, placed in the
+toplevel of the git tree. If you're not sure where a configuration
+option is coming from, check if there is a ``.b4-config`` file in the
+repository you're currently using.
 
 Configuration options
 ---------------------
-All settings are under the ``b4`` section.
+All settings are under the ``b4`` section. E.g to set a ``b4.midmask``
+option, you can just edit your ``~/.gitconfig`` or ``.git/config`` file
+and add the following section::
+
+    [b4]
+      midmask = https://some.host/%s
 
 Core options
 ~~~~~~~~~~~~
@@ -98,6 +107,9 @@ These options control many of the core features of b4.
   own Signed-off-by trailer is always at the bottom of your own custody
   section).
 
+  Note: versions prior to v0.10 did not properly respect the chain of
+  custody.
+
   Default: ``*``
 
 ``b4.cache-expire``
@@ -133,7 +145,6 @@ These settings control how ``b4 shazam`` applies patches to your tree.
 
 Attestation settings
 ~~~~~~~~~~~~~~~~~~~~
-These settings control patch attestation.
 
 ``b4.attestation-policy``
   B4 supports domain-level and end-to-end attestation of patches using
@@ -141,7 +152,7 @@ These settings control patch attestation.
 
   * ``off``: do not bother checking attestation at all
   * ``check``: print green checkmarks when attestation is passing, but
-    nothing if attestation is failing (DEPRECATED, use ``softfail``)
+    nothing if attestation is failing (**DEPRECATED**, use ``softfail``)
   * ``softfail``: print green checkmarks when attestation is passing and
     red x-marks when it is failing
   * ``hardfail``: exit with an error when any attestation checks fail
@@ -228,11 +239,15 @@ These settings control the behaviour of ``b4 ty`` command.
   A comma-separated list of shell-style globbing patterns with addresses
   that should always be excluded from the recipient list.
 
-``b4.sendemail-identity``
+  Default: ``None``
+
+``b4.sendemail-identity`` (v0.8+)
   Sendemail identity to use when sending mail directly from b4 (applies
   to ``b4 send`` and ``b4 ty``). See ``man git-send-email`` for info
   about sendemail identities.
 
+  Default: ``None``
+
 
 .. _patchwork_settings:
 
@@ -287,35 +302,55 @@ Contributor-oriented settings
 ``b4.send-endpoint-web`` (v0.10+)
   The web submission endpoint to use (see :ref:`web_endpoint`).
 
+  Default: ``None``
+
 ``b4.send-series-to`` (v0.10+)
   Address or comma-separated addresses to always add to the To: header
   (see :ref:`prep_recipients`).
 
+  Default: ``None``
+
 ``b4.send-series-cc`` (v0.10+)
-  Address or comma-separated addresses to always add to the To: header
+  Address or comma-separated addresses to always add to the Cc: header
   (see :ref:`prep_recipients`).
 
+  Default: ``None``
+
 ``b4.send-no-patatt-sign`` (v0.10+)
-  Do not sign patches with patatt before sending them (ignored when
-  using the web submission endpoint).
+  Do not sign patches with patatt before sending them (unless using the
+  web submission endpoint where signing is required).
+
+  Default: ``no``
 
 ``b4.send-hide-cover-to-cc`` (v0.10+)
   Always hide To: and Cc: trailers from the cover letter, just include
   them into the corresponding message recipient headers.
 
+  Default: ``no``
+
 ``b4.send-auto-to-cmd`` (v0.10+)
-  Alternative command to use to generate the list of To: recipients.
+  Command to use to generate the list of To: recipients. Has no effect
+  if the specified script is not found in the repository.
+
+  Default: ``scripts/get_maintainer.pl --nogit --nogit-fallback --nogit-chief-penguins --norolestats --nol``
 
 ``b4.send-auto-cc-cmd`` (v0.10+)
-  Alternative command to use to generate the list of Cc: recipients.
+  Command to use to generate the list of Cc: recipients. Has no effect
+  if the specified script is not found in the repository.
+
+  Default:: ``scripts/get_maintainer.pl --nogit --nogit-fallback --nogit-chief-penguins --norolestats --nom``
+
 
 ``b4.prep-cover-strategy`` (v0.10+)
-  Alternative cover letter storage strategy to use (see
-  :ref:`prep_cover_strategies`).
+  Alternative cover letter storage strategy to use (see :ref:`prep_cover_strategies`).
+
+  Default: ``commit``
 
 ``b4.prep-cover-template`` (v0.10+)
   Path to the template to use for the cover letter.
 
+  Default: ``None``
+
 
 To document
 -----------
diff --git a/docs/contributor/overview.rst b/docs/contributor/overview.rst
index 6f62105..d2d531b 100644
--- a/docs/contributor/overview.rst
+++ b/docs/contributor/overview.rst
@@ -12,7 +12,7 @@ easier for contributors to submit patch series:
 * ``b4 prep`` allows to get your patch series ready for sending to the
   maintainer for review
 * ``b4 send`` simplifies the process of submitting your patches to the
-  upstream maintainer even if you don't have access to a very good SMTP
+  upstream maintainer even if you don't have access to a compliant SMTP
   server
 * ``b4 trailers`` simplifies the process of retrieving code-review
   trailers received on the distribution lists and applying them to your
@@ -26,6 +26,9 @@ easier for contributors to submit patch series:
   and to always check things with ``--dry-run`` when that option is
   available.
 
+  If you come across a bug or unexpected behaviour, please report the
+  problem to the Tools mailing list.
+
 Do I still need to be able to send email?
 -----------------------------------------
 While ``b4 send`` makes it possible to submit patches without having
@@ -33,14 +36,15 @@ access to an SMTP server, you still need a reasonable mail server for
 participating in conversations and code review.
 
 The main benefit of ``b4 send`` is that you no longer have to really
-care if your SMTP server performs some kind of content mangling that
-causes patches to become corrupted.
+care if your mail server performs some kind of content mangling that
+causes patches to become corrupted, or if it doesn't provide a way to
+send mail via SMTP.
 
 What is the b4 contributor workflow?
 ------------------------------------
-The workflow is still very git-oriented, so you should expect to need to
-know a lot about such git commands like ``git amend`` and ``git
-rebase -i``. In general, the process goes like this:
+The workflow is very much git-oriented, so you should expect to need to
+know a lot about such git commands like ``git amend`` and ``git rebase
+-i``. In general, the process goes like this:
 
 1. Prepare your patch series by using ``b4 prep`` and queueing your
    commits. Use ``git rebase -i`` to arrange the commits in the right
@@ -72,7 +76,7 @@ rebase -i``. In general, the process goes like this:
    feedback you receive. Remember to record these changes in the cover
    letter's changelog.
 
-9. Unless series accepted upstream, GOTO 3.
+9. Unless series is accepted upstream, GOTO 3.
 
 Please read the rest of these docs for details on the ``prep``,
 ``send``, and ``trailers`` subcommands.
diff --git a/docs/contributor/prep.rst b/docs/contributor/prep.rst
index 3eefe00..b31ed8c 100644
--- a/docs/contributor/prep.rst
+++ b/docs/contributor/prep.rst
@@ -3,12 +3,11 @@ prep: preparing your patch series
 The first stage of contributor workflow is to prepare your patch series
 for submission upstream. It generally consists of the following stages:
 
-1. start a new topical branch using ``b4 prep -n``
+1. start a new topical branch using ``b4 prep -n topical-name``
 2. add commits as usual and work with them using ``git rebase -i``
 3. prepare the cover letter using ``b4 prep --edit-cover``
 4. prepare the list of recipients using ``b4 prep --auto-to-cc``
 
-
 Starting a new topical branch
 -----------------------------
 When you are ready to start working on a new submission, the first step
@@ -16,24 +15,22 @@ is to create a topical branch::
 
     b4 prep -n descriptive-name [-f tagname]
 
-.. note::
-
-   It is important to give your branch a succinct descriptive name,
-   because it will become part of the unique ``change-id`` that will be
-   used to track your proposal across revisions. In other words, don't
-   call it "stuff" or "foo".
-
-.. note::
-
-   Generally, you will want to fork from some known point in the
-   history, not from a random HEAD commit. You can use ``-f`` to specify
-   a fork-point for b4 to use, such as a recent tag name.
+It is important to give your branch a short descriptive name, because it
+will become part of the unique ``change-id`` that will be used to track
+your proposal across revisions. In other words, don't call it "stuff" or
+"foo".
 
 This command will do the following:
 
 1. Create a new branch called ``b4/descriptive-name`` and switch to it.
 2. Create an empty commit with a cover letter template.
 
+.. note::
+
+   Generally, you will want to fork from some known point in the
+   history, not from some random HEAD commit. You can use ``-f`` to
+   specify a fork-point for b4 to use, such as a recent tag name.
+
 You can then edit the cover letter using::
 
     b4 prep --edit-cover
@@ -69,7 +66,7 @@ For this reason, b4 supports alternative strategies for storing the
 cover letter, which can be set using the ``b4.prep-cover-strategy``
 configuration variable.
 
-``commit`` strategy
+``commit`` strategy (default)
   This is the default strategy that keeps the cover letter and all
   tracking information in an empty commit at the start of your series.
   See above for upsides and downsides.
@@ -108,11 +105,11 @@ configuration variable.
   * allows you to push the series to a remote and pull it from a
     different location to continue working on a series
   * editing the cover letter does not rewrite commit history, which may
-    be easier for working in teams
+    be easier when working in teams
 
   Downsides:
 
-  * adding new commits is more complicated, because you have to
+  * adding new commits is a bit more complicated, because you have to
     immediately rebase them to be in front of the cover letter
   * you have to rely on the base branch for keeping track of where your
     series starts
@@ -126,8 +123,8 @@ configuration variable.
 Enrolling an existing branch
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 If you've already started working on a set of commits without first
-preparing a topical branch using ``b4 prep -n``, you can enroll your
-existing branch as well.
+running ``b4 prep -n``, you can enroll your existing branch to make it
+"prep-tracked."
 
 For example, if you have a branch called ``my-topical-branch`` that was
 forked from ``master``, you can enroll it with b4::
@@ -158,11 +155,11 @@ and you can work with them using any regular git tooling:
 * you can rebase them on a different (or an updated) branch using ``git
   rebase``
 * you can amend (reword, split, squash, etc) commits interactively using
-  ``git rebase -i``; there are many excellent tutorials available on how
-  to use interactive rebase
+  ``git rebase -i``; there are many excellent tutorials available online
+  on how to use interactive rebase
 
-Unless you are using a very old version of git, your empty cover commit
-should be preserved through all rebase operations.
+Unless you are using a very old version of git, your empty cover letter
+commit should be preserved through all rebase operations.
 
 .. note::
 
@@ -171,18 +168,27 @@ should be preserved through all rebase operations.
    you do want to edit it directly using ``git rebase -i``, remember to
    use ``git commit --allow-empty`` to commit it back into the tree.
 
+What if I only have a single patch?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Even if you only have a single commit, you should still treat it as a
+single-patch series and send it along with a cover letter. It is very
+likely that you will be asked to make some changes to your patch or
+split it into several patches. Having a cover letter will help retain
+the change-id of the series across revisions, and will provide a
+convenient place to keep the changelog of revisions.
+
 .. _prep_recipients:
 
 Prepare the list of recipients
 ------------------------------
-When you are getting ready to submit your work, you should figure out
+When you are getting ready to submit your work, you need to figure out
 who the recipients of your series should be. By default, b4 will send
 the series to any address mentioned in the trailers (and to any other
 addresses you tell it to use).
 
 For the Linux kernel, a required step is to gather the recipients from
 the output of ``get_maintainer.pl``, which b4 will do for you
-automatically when you run the auto-to-cc command::
+automatically when you run the ``auto-to-cc`` command::
 
     b4 prep --auto-to-cc
 
@@ -199,10 +205,16 @@ repository's ``.git/config`` file as follows::
     [b4]
       send-series-to = some@list.name
 
+This may also be already set by the project, if they have a
+``.b4-config`` file in the root of their git repository.
+
 .. _prep_flags:
 
 Prep command flags
 ------------------
+Please also see :ref:`contributor_settings`, which allow setting
+or modifying defaults for some of these flags.
+
 ``-c, --auto-to-cc``
   Automatically populate the cover letter with addresses collected from
   commit trailers. If a ``MAINTAINERS`` file is found, together with
diff --git a/docs/contributor/send.rst b/docs/contributor/send.rst
index a6a31d5..4f56835 100644
--- a/docs/contributor/send.rst
+++ b/docs/contributor/send.rst
@@ -13,12 +13,13 @@ Upsides of using your own SMTP server:
 
 However, using your own SMTP server may not always be a valid option:
 
+* your mail provider may not offer an SMTP compliant server for sending
+  mail (e.g. if it only uses a webmail/exchange client)
+* there may be limits on the number of messages you can send through
+  your SMTP server in a short period of time (which is normal for large
+  patch series)
 * your company SMTP server may modify the message bodies by adding huge
   legal disclaimers to all outgoing mail
-* there may be limits on the number of messages you can send in a short
-  period of time (which is normal for large patch series)
-* your company mail system may not provide an SMTP compliant server for
-  sending mail (e.g. if it only uses a webmail/exchange client)
 
 The web submission endpoint helps with such cases, plus offers several
 other upsides:
@@ -31,7 +32,7 @@ other upsides:
 .. note::
 
    Even if you opt to use the web submission endpoint, you still need a
-   valid email address for participating in decentralized development --
+   valid email account for participating in decentralized development --
    you will need it to take part in discussions and for sending and
    receiving code review feedback.
 
@@ -41,8 +42,8 @@ Authenticating with the web submission endpoint
 -----------------------------------------------
 Before you start, you will need to configure your attestation mechanism.
 If you already have a PGP key configured for use with git, you can just
-use that. Alternatively, you can set up your own ed25519 key for just
-this purpose.
+use that and skip the next section. If you don't already have a PGP key,
+you can create a separate ed25519 key just for web submission purposes.
 
 Creating a new ed25519 key
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -53,8 +54,7 @@ Creating a new ed25519 key
    setting.
 
 Installing b4 should have already pulled in the patatt patch attestation
-library. To start using the web submission endpoint, you will need to
-create a key::
+library. You can use the command line tool to create your ed25519 key::
 
     $ patatt genkey
     Generating a new ed25519 keypair
@@ -110,7 +110,8 @@ below::
 
 As the instructions say, you should receive a verification email to the
 address you specified in your ``user.email``. Once you have received it,
-run the verification command using the UUID from the email::
+run the verification command by copy-pasting the UUID from the
+confirmation message::
 
     $ b4 send --web-auth-verify abcd9b34-2ecf-4d25-946a-0631c414227e
     Signing challenge
@@ -167,7 +168,7 @@ The following happens after you send your patches:
 
 * b4 will automatically create a detached head containing the commits
   from your sent series and tag it with the contents of the cover
-  letter; this creates a historical record of your submissions, as well
+  letter; this creates a historical record of your submission, as well
   as adds a way to easily resend a previously sent series
 * b4 will reroll your series to the next version, so that if you just
   sent off a ``v1`` of the series, the working version will be marked as
@@ -203,15 +204,15 @@ Command line flags
 ``--no-trailer-to-cc``
   Do not add any addresses found in the cover or patch trailers to To:
   or Cc:. This is usually handy for testing purposes, in case you want
-  to send a set of patches to yourself. Can be set in the configuration
-  file using the ``b4.send-hide-cover-to-cc`` option (see
-  :ref:`contributor_settings`).
+  to send a set of patches to yourself. 
 
 ``--hide-cover-to-cc``
   It is common for the ``To:`` and ``Cc:`` sections in cover letters to
   be pretty large on large patch sets. Passing this flag will remove
   these trailers from the cover letter, but still add the addresses to
-  the corresponding To: and Cc: headers.
+  the corresponding To: and Cc: headers. This can be made permanent in
+  the configuration file using the ``b4.send-hide-cover-to-cc`` option
+  (see :ref:`contributor_settings`).
 
 ``--to``
   Add any more email addresses to include into the To: header here
diff --git a/docs/contributor/trailers.rst b/docs/contributor/trailers.rst
index fb88c0d..4f7697b 100644
--- a/docs/contributor/trailers.rst
+++ b/docs/contributor/trailers.rst
@@ -1,15 +1,15 @@
 trailers: retrieving code-review trailers
 =========================================
 This commands allows you to easily retrieve code-review trailers sent in
-reply to your work and apply them to the matching commits. It will
-retrieve code-review trailers sent in response to any previously
-submitted versions of your series, as long as:
+reply to your work and apply them to the matching commits. It should
+locate code-review trailers sent in response to any previously submitted
+versions of your series, as long as:
 
 * either the patch-id of the commit still matches what was sent, or
 * the title of the commit is exactly the same
 
 You can always edit the trailers after they are applied by using ``git
-rebase -i`` and choosing ``reword`` as action.
+rebase -i`` and choosing ``reword`` as rebase action.
 
 Most commonly, you just need to run::
 
diff --git a/docs/index.rst b/docs/index.rst
index 6f29d41..5a5a9e5 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -1,8 +1,8 @@
 B4 end-user documentation
 =========================
-B4 is a tool created to make it easier for project maintainers to use a
-distributed development workflow that relies on patches and distribution
-lists for code contributions and review.
+B4 is a tool created to make it easier for project developers and
+maintainers to use a distributed development workflow that relies on
+patches and distribution lists for code contributions and review.
 
 This documentation is split into two main areas -- one aimed at
 maintainers who primarily receive, review, and apply patches to their
diff --git a/docs/installing.rst b/docs/installing.rst
index e19baf3..c1a00a2 100644
--- a/docs/installing.rst
+++ b/docs/installing.rst
@@ -16,7 +16,7 @@ If that is the case, you can install it from other sources.
 
 Installing with pip
 -------------------
-To install from pypi::
+To install from PyPi::
 
     python3 -m pip install --user b4
 
@@ -26,7 +26,7 @@ that your ``~/.local/bin/`` is in your ``$PATH``.
 
 Upgrading
 ~~~~~~~~~
-If you have previously installed from pypi, you can upgrade using pip as
+If you have previously installed from PyPi, you can upgrade using pip as
 well::
 
     python3 -m pip install --user --upgrade b4
diff --git a/docs/maintainer/am-shazam.rst b/docs/maintainer/am-shazam.rst
index 1ef0604..75864ca 100644
--- a/docs/maintainer/am-shazam.rst
+++ b/docs/maintainer/am-shazam.rst
@@ -8,9 +8,9 @@ via distribution lists. The base functionality is similar to that of
 
 This will do the following:
 
-1. look up if that message-id is known by the public-inbox server
-   (e.g. lore.kernel.org)
-2. retrieve all threads matching that message-id
+1. look up if that message-id is known on the specified public-inbox
+   server (e.g. lore.kernel.org)
+2. retrieve the full thread containing that message-id
 3. process all replies to collect code review trailers and apply them to
    the relevant patch commit messages
 4. perform attestation checks on patches and code review follow-ups
@@ -45,10 +45,11 @@ b4 am vs. b4 shazam
 
 The two commands are very similar -- the main distinction is that ``b4
 am`` will prepare the patch series for application to the git tree, but
-will not modify your git tree in any way.
+will not make any modifications to your current branch.
 
 The ``b4 shazam`` command will do the same as ``b4 am`` *and* will apply
-the patch series to the git tree (if it is possible to do so cleanly).
+the patch series to the current branch (if it is possible to do so
+cleanly).
 
 Common flags
 ------------
@@ -70,25 +71,6 @@ The following flags are common to both commands:
   This lets you force b4 to ignore cache and retrieve the latest
   results.
 
-``-o OUTDIR, --outdir OUTDIR``
-  Instead of writing the .mbox file to the current directory, write it
-  to this location instead. You can also pass a path to an existing
-  mbox or maildir location to have the results appended to that mailbox
-  instead (see also the ``-f`` flag below).
-
-  When ``-`` is specified, the output is dumped to stdout.
-
-``-c, --check-newer-revisions``
-  When retrieving patch series, check if a newer revision is available.
-  For example, if you are trying to retrieve a series titled ``[PATCH v2
-  0/3]``, b4 will use a number of mechanisms to check if a ``v3`` or
-  later revision is also available and will add these results to the
-  retrieved thread.
-
-``-n WANTNAME, --mbox-name WANTNAME``
-  By default, the resulting mailbox file will use the message-id as the
-  basis for its filename. This option lets you override this behaviour.
-
 ``-v WANTVER, --use-version WANTVER``
   If a thread (or threads, when used with ``-c``) contains multiple
   patch series revisions, b4 will automatically pick the highest
@@ -148,7 +130,7 @@ The following flags are common to both commands:
 
 ``--cc-trailers``
   Copies all addresses found in the message Cc's into ``Cc:`` commit
-  message trailers.
+  trailers.
 
 ``--no-parent``
   Break thread at the msgid specified and ignore any parent messages.
@@ -165,12 +147,32 @@ The following flags are common to both commands:
   legitimately useful in the code, so b4 will print a warning and bail
   out when it finds them. However, just in case there are legitimate
   reasons for these characters to be in the code (e.g. as part of
-  translated documentation), this behaviour can be overridden.
+  documentation translated into LTR languages), this behaviour can be
+  overridden.
 
 Flags only valid for ``b4 am``
 ------------------------------
 The following flags only make sense for ``b4 am``:
 
+``-o OUTDIR, --outdir OUTDIR``
+  Instead of writing the .mbox file to the current directory, write it
+  to this location instead. You can also pass a path to an existing
+  mbox or maildir location to have the results appended to that mailbox
+  instead (see also the ``-f`` flag below).
+
+  When ``-`` is specified, the output is dumped to stdout.
+
+``-c, --check-newer-revisions``
+  When retrieving patch series, check if a newer revision is available.
+  For example, if you are trying to retrieve a series titled ``[PATCH v2
+  0/3]``, b4 will use a number of mechanisms to check if a ``v3`` or
+  later revision is also available and will add these results to the
+  retrieved thread.
+
+``-n WANTNAME, --mbox-name WANTNAME``
+  By default, the resulting mailbox file will use the message-id as the
+  basis for its filename. This option lets you override this behaviour.
+
 ``-M, --save-as-maildir``
   By default, the retrieved thread will be saved as an mbox file.
   However, due to subtle incompatibilities between various mbox formats
@@ -195,7 +197,7 @@ The following flags only make sense for ``b4 am``:
 
 ``-3, --prep-3way``
   This will try to prepare your tree for a 3-way merge by doing some
-  behind the scenes git magic and preparing some fake commits.
+  behind the scenes git magic and preparing some fake loose commits.
 
 ``--no-cover``
   By default, b4 will save the cover letter as a separate file in the
@@ -243,7 +245,7 @@ the basis for the merge commit.
          git merge --no-ff -F .git/b4-cover --edit FETCH_HEAD --signoff
 
   Generally, this command is also a good test for "will this patch
-  series apply cleanly to my tree". You can perform any actions with the
+  series apply cleanly to my tree." You can perform any actions with the
   ``FETCH_HEAD`` as you normally would, e.g. run ``git diff``, make a
   new branch out of it using ``git checkout``, etc.
 
diff --git a/docs/maintainer/diff.rst b/docs/maintainer/diff.rst
index f3ac253..cea2927 100644
--- a/docs/maintainer/diff.rst
+++ b/docs/maintainer/diff.rst
@@ -49,7 +49,8 @@ Optional flags
 
 ``-o OUTDIFF, --output-diff OUTDIFF``
   **(DEPRECATED)** Sends ``range-diff`` output into a file. You should use
-  ``-n`` instead and redirect output from there.
+  ``-n`` instead and redirect output from the actual ``git range-diff``
+  command.
 
 ``-c, --color``
   **(DEPRECATED)** Show colour output even when outputting into a file.
diff --git a/docs/maintainer/ty.rst b/docs/maintainer/ty.rst
index 589c4ae..444badf 100644
--- a/docs/maintainer/ty.rst
+++ b/docs/maintainer/ty.rst
@@ -8,7 +8,7 @@ Tracking retrieved patches and PRs
 Any patches or pull requests you retrieve with ``b4 am,shazam,pr`` will
 be automatically tracked by b4 in your homedir (usually, in
 ``$HOME/.local/share/b4``, but may vary if your ``$XDG_DATA_HOME`` is
-set to a different value). There are three 4 kids of files in that
+set to a different value). There are four kinds of files in that
 directory:
 
 * .am: contain information about patches retrieved with ``b4 am`` or
@@ -22,8 +22,8 @@ directory:
 All of these files contain JSON data about the series or pull requests
 being tracked.
 
-Using the --auto thankanator
-----------------------------
+Using the Auto-Thankanator
+--------------------------
 If you've retrieved and applied some patches to your tree, you should be
 able to fire up the "auto-thankanator", which uses patch-id and commit
 subject tracking to figure out which series from those you have