docs: Add comma to all uses of "e.g." in contributor docs.

docs/testing/linters.md

@@ -172,7 +172,7 @@ is the extent of our checking.
 Finally, we're checking line length in Python code (and hope to extend
 this to other parts of the codebase soon). You can use
 `#ignorelinelength` for special cases where a very long line makes
-sense (e.g. a link in a comment to an extremely long URL).
+sense (e.g., a link in a comment to an extremely long URL).
 
 #### Python code
 

docs/testing/philosophy.md

@@ -160,7 +160,7 @@ So, to summarize our approach to integration vs. unit testing:
   HTTP response and the internal state of the server following the request
   are both correct.
 - Following the end-to-end principle in system design, where possible
-  we write tests that execute a complete flow (e.g. registering a new
+  we write tests that execute a complete flow (e.g., registering a new
   Zulip account) rather than testing the implementations of individual
   functions.
 - We invest in the performance of Zulip in part to give users a great
@@ -214,7 +214,7 @@ test conditions.
 The benefit of this strategy is that you guarantee that the test setup
 only differs as intended: Done well, it helps avoid the otherwise
 extremely common failure mode where a `test_foo_failure` test passes
-for the wrong reason. (E.g. the action fails not because of the
+for the wrong reason. (e.g., the action fails not because of the
 permission check, but because a required HTTP parameter was only added
 to an adjacent `test_foo_success`).
 

docs/testing/testing-with-django.md

@@ -121,7 +121,7 @@ Here are some example action methods that tests may use for data setup:
 
 ### Testing code that accesses the filesystem
 
-Some tests need to access the filesystem (e.g. `test_upload.py` tests
+Some tests need to access the filesystem (e.g., `test_upload.py` tests
 for `LocalUploadBackend` and the data import tests). Doing
 this correctly requires care to avoid problems like:
 
@@ -142,7 +142,7 @@ To avoid these problems, you can do the following:
   avoid conflicts with other tests run later by the same test process.
 
 Our common testing infrastructure handles some of this for you,
-e.g. it replaces `settings.LOCAL_UPLOADS_DIR` for each test process
+e.g., it replaces `settings.LOCAL_UPLOADS_DIR` for each test process
 with a unique path under `/var/<uuid>/test-backend`. And
 `UploadSerializeMixin` manages some of the cleanup work for
 `test_upload.py`.
@@ -252,7 +252,7 @@ foo.qux = 42
 ```
 
 is _not_ going to throw any errors. Our mock silently accepts all these calls and records them.
-`Mock` also implements methods for us to access and assert its records, e.g.
+`Mock` also implements methods for us to access and assert its records, e.g.,
 
 ```python
 foo.bar.assert_called_with('quux')

docs/testing/testing-with-node.md

@@ -274,7 +274,7 @@ These instructions assume you're using the Vagrant development environment.
       1. In the `Configure Node.js Remote Interpreter`, window select `Vagrant`
       1. Wait for WebStorm to connect to Vagrant. This will be displayed
          by the `Vagrant Host URL` section updating to contain the Vagrant
-         SSH URL, e.g. `ssh://vagrant@127.0.0.1:2222`.
+         SSH URL, e.g., `ssh://vagrant@127.0.0.1:2222`.
       1. **Set the `Node.js interpreter path` to `/usr/local/bin/node`**
       1. Hit `OK` 2 times to get back to the `Run/Debug Configurations` window.
    1. Under `Working Directory` select the root `zulip` directory.
@@ -288,7 +288,7 @@ Congratulations! You've now set up the integration.
 To use Webstorm to debug a given node test file, do the following:
 
 1. Under `Application parameters` choose the node test file that you
-   are trying to test (e.g. `web/tests/message_store.test.js`).
+   are trying to test (e.g., `web/tests/message_store.test.js`).
 1. Under `Path Mappings`, set `Project Root` to `/srv/zulip`
    (i.e. where the `zulip` Git repository is mounted in the Vagrant guest).
 1. Use the WebStorm debugger; see [this overview][webstorm-debugging]

docs/testing/testing-with-puppeteer.md

@@ -3,8 +3,8 @@
 While our [node test suite](testing-with-node.md) is the
 preferred way to test most frontend code because they are easy to
 write and maintain, some code is best tested in a real browser, either
-because of navigation (E.g. login) or because we want to verify the
-interaction between Zulip logic and browser behavior (E.g. copy/paste,
+because of navigation (e.g., login) or because we want to verify the
+interaction between Zulip logic and browser behavior (e.g., copy/paste,
 keyboard shortcuts, etc.).
 
 ## Running tests
@@ -74,7 +74,7 @@ integration](continuous-integration.md):
   affects any of the selectors used in the tests? If so, the test may
   just need to be updated for your changes.
 - Does the test fail deterministically when you run it locally using
-  E.g. `./tools/test-js-with-puppeteer compose.ts`? If so, you can
+  e.g., `./tools/test-js-with-puppeteer compose.ts`? If so, you can
   iteratively debug to see the failure.
 - Does the test fail nondeterministically? If so, the problem is
   likely that a `waitForSelector` statement is either missing or not
@@ -141,7 +141,7 @@ notes above:
   `main`.
 - With black-box browser tests like these, it's very important to write your code
   to wait for browser's UI to update before taking any action that
-  assumes the last step was processed by the browser (E.g. after you
+  assumes the last step was processed by the browser (e.g., after you
   click on a user's avatar, you need an explicit wait for the profile
   popover to appear before you can try to click on a menu item in that
   popover). This means that before essentially every action in your

docs/testing/testing.md

@@ -40,7 +40,7 @@ typically involve running subsets of the tests with commands like these:
 ```
 
 The commands above will all run in just a few seconds. Many more
-useful options are discussed in each tool's documentation (e.g.
+useful options are discussed in each tool's documentation (e.g.,
 `./tools/test-backend --help`).
 
 ## Major test suites
@@ -117,7 +117,7 @@ reasons:
 
 As a result, Zulip's major test suites should never access the
 Internet directly. Since code in Zulip does need to access the
-Internet (e.g. to access various third-party APIs), this means that
+Internet (e.g., to access various third-party APIs), this means that
 the Zulip tests use mocking to basically hardcode (for the purposes of
 the test) what responses should be used for any outgoing Internet
 requests that Zulip would make in the code path being tested.

docs/testing/typescript.md

@@ -71,7 +71,7 @@ Our plan is to order which modules we migrate carefully, starting with
 those that:
 
 - Appear frequently as reverse dependencies of other modules
-  (e.g. `people.js`). These are most valuable to do first because
+  (e.g., `people.js`). These are most valuable to do first because
   then we have types on the data being interacted with by other
   modules when we migrate those.
 - Don't have large open pull requests (to avoid merge conflicts); one
@@ -82,11 +82,11 @@ those that:
 
 When migrating a module, we want to be especially thoughtful about
 putting together a commit structure that makes mistakes unlikely and
-the changes easy to verify. E.g.:
+the changes easy to verify. E.g.,:
 
 - First a commit that just converts the language to TypeScript adding
   types. The result may potentially have some violations of the
-  long-term style we want (e.g. not using `const`). Depending on how
+  long-term style we want (e.g., not using `const`). Depending on how
   we're handling linting, we set some override eslint rules at the top
   of the module at this stage so CI still passes.
 - Then a commit just migrating use of `var` to `const/let` without