docs: Fix a few grammar issues in documentation.

docs/documentation/integrations.md

@@ -23,14 +23,14 @@ Usually, this involves a few steps:
   message (which is important for the screenshots to be updated as
   Zulip's design changes).
 
-* You'll need to add a SVG graphic
+* You'll need to add an SVG graphic
   of your integration's logo under the
   `static/images/integrations/logos/<name>.svg`, where `<name>` is the
   name of the integration, all in lower case; you can usually find them in the
   product branding or press page. Make sure to optimize the SVG graphic by
   running `yarn run svgo -f path-to-file`.
 
-  If you cannot find a SVG graphic of the logo, please find and include a PNG
+  If you cannot find an SVG graphic of the logo, please find and include a PNG
   image of the logo instead.
 
 * Run `tools/setup/generate_integration_bots_avatars.py` to generate a smaller
@@ -70,7 +70,7 @@ always create a new macro by adding a new file to that folder.
 Here are a few common macros used to document Zulip's integrations:
 
 * `{!create-stream.md!}` macro - Recommends that users create a dedicated
-  stream for a given integration. Usually the first step in setting up an
+  stream for a given integration. Usually the first step is setting up an
   integration or incoming webhook. For an example rendering, see **Step 1** of
   [the docs for Zulip's GitHub integration][GitHub].
 
@@ -155,7 +155,7 @@ similar integration and edit it. [Basecamp][basecamp] is a good one to copy.
 
 ### General writing guidelines
 
-At at high level, the goals are for the instructions to feel simple, be easy to
+At a high level, the goals are for the instructions to feel simple, be easy to
 follow, and be easy to maintain. Easier said than done, but here are a few
 concrete guidelines.
 

docs/documentation/overview.md

@@ -75,7 +75,7 @@ Zulip has around 10 HTML documentation pages under `templates/zerver`
 for specific major topics, like the features list, client apps,
 integrations, hotkeys, API bindings, etc.  These documents often have
 somewhat complex HTML and JavaScript, without a great deal of common
-pattern between them other than inheriting from the `portico.html`
+patterns between them other than inheriting from the `portico.html`
 template.  We generally avoid adding new pages to this collection
 unless there's a good reason, but we don't intend to migrate them,
 either, since this system gives us the flexibility to express these

docs/documentation/user.md

@@ -75,7 +75,7 @@ documentation. It's worth remembering that for most articles, almost 100% of
 the users of the feature will never read the article. Instructions for
 filling out forms, interacting with UI widgets (e.g. typeaheads),
 interacting with modals, etc. should never go in user documentation.
-In such cases you may be able to fix the problem by adding text in-app,
+In such cases, you may be able to fix the problem by adding text in-app,
 where the user will see it as they are interacting with the feature.
 
 ### User interface
@@ -113,7 +113,7 @@ documentation.
 ### Images
 
 Images and screenshots should be included in user documentation only
-if it will help guide the user in how to do something (e.g. if the
+if they will help guide the user in how to do something (e.g. if the
 image will make it much clearer which element on the page the user
 should interact with).  For instance, an image of an element should
 not be included if the element the user needs to interact with is the