Merge docs from the wiki

[steve-mcintyre]

No description provided.

[aronowski]

I introduced some minor tweaks to the documentation that haven't been yet added to this PR.

I'd like to attach the requested patch file, but apparently GitHub doesn't let me, despite saying that .patch files are supported(sic!), so I'll paste it as-is:

From f4a104461b46f3b50f7af56aeb0f8bdf7004a49f Mon Sep 17 00:00:00 2001
From: Kamil Aronowski <[email protected]>
Date: Tue, 19 Sep 2023 15:34:40 +0200
Subject: [PATCH] Minor spelling fixes

Signed-off-by: Kamil Aronowski <[email protected]>
---
 reviewer-guidelines.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/reviewer-guidelines.md b/reviewer-guidelines.md
index 27cbf50..b7845bb 100644
--- a/reviewer-guidelines.md
+++ b/reviewer-guidelines.md
@@ -44,7 +44,7 @@ First of all, there are some higher-level things to consider:
    1. Not providing a Dockerfile that works, or one that makes it hard
       for you to see what's going on.
 
-   1. Mot providing all the details of their other binaries, or maybe
+   1. Not providing all the details of their other binaries, or maybe
       being vague about them. It's easy to miss this kind of thing
       when submitting, and we should be looking for these. It's most
       likely just something's that been missed, but we should be
@@ -107,7 +107,7 @@ sure.
 
 Ideally, the build should be made using the exact source tarball
 referenced in the submission guidelines, but so long as the source is
-**clearly** the same then it's acceptable to use a git repo instead.
+**clearly** the same, then it's acceptable to use a git repo instead.
 
 We can no longer accept shim signing submissions for versions before
 **15.7**.
@@ -142,7 +142,7 @@ data:
 Is SBAT data present in the provided binaries, and does it match what
 was provided in the answers to issue template questions?
 
-Is the vendor extension sensible? A clear unique name is good,
+Is the vendor extension sensible? A clear, unique name is good,
 something that's too likely to clash with another vendor is bad. Too
 long or too short an extension is not wanted, etc.
 
@@ -164,7 +164,7 @@ If grub is used:
    the submitter and well understood? This can be **very**
    time-consuming to do right - if a vendor is doing their own novel
    patches we may need to get more reviews.
-1. Which grub modules are built in? The smaller the better here, for
+1. Which grub modules are built in? The smaller, the better here, for
    the sake of reduced attack surface. Some of the more obscure grub
    filesystem modules have patchy security history and are best left
    disabled.
@@ -192,7 +192,7 @@ Does the submitter adequately address how secure boot is enforced in
 their boot stack and how their boot stack prevents execution of
 unauthenticated code?
 
-## Working with shim-review github issues
+## Working with shim-review GitHub issues
 
 Except for sending the contact verification mails (see above), please
 keep all communications in the issues.
@@ -200,10 +200,10 @@ keep all communications in the issues.
 We have a small set of labels that can be attached to review
 submissions to help us track things. These should be self-explanatory,
 I hope! The correct labels should also act to give clear information
-to submitters. **Iff** you're a known reviewer you can
+to submitters. **If** you're a known reviewer, you can
 add/remove/modify labels as you see fit.
 
 We should never add the ``accepted`` label until a submission is
 considered complete and ready for signing. Once a submission has been
 signed, submitters should be encouraged to mark their shim-review
-issues as **closed**.
+issues as **closed**.
\ No newline at end of file
-- 
2.41.0