--- a/toolkit/components/telemetry/docs/collection/custom-pings.rst
+++ b/toolkit/components/telemetry/docs/collection/custom-pings.rst
@@ -16,47 +16,47 @@ Custom pings can be submitted from JavaS
    - ``overrideEnvironment`` - a JSON style object that overrides the environment data
 
 ``TelemetryController`` will assemble a ping with the passed payload and the specified options.
 That ping will be archived locally for use with Shield and inspection in ``about:telemetry``.
 If the preferences allow upload of Telemetry pings, the ping will be uploaded at the next opportunity (this is subject to throttling, retry-on-failure, etc.).
 
 .. important::
 
-    Every new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for :bsmedberg or one of the other data peers. We try to reply within a business day.
+    Every new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for one of the data peers. We try to reply within a business day.
 
 Submission constraints
 ----------------------
 
 When submitting pings on shutdown, they should not be submitted after Telemetry shutdown.
 Pings should be submitted at the latest within:
 
-- the `observer notification <https://developer.mozilla.org/de/docs/Observer_Notifications#Application_shutdown>`_ ``"profile-before-change"``
+- the `observer notification <https://developer.mozilla.org/docs/Observer_Notifications#Application_shutdown>`_ ``"profile-before-change"``
 - the :ref:`AsyncShutdown phase <AsyncShutdown_phases>` ``sendTelemetry``
 
 There are other constraints that can lead to a ping submission getting dropped:
 
-- invalid ping type strings
+- invalid ping type strings.
 - invalid payload types: E.g. strings instead of objects.
-- oversized payloads: We currently only drop pings >1MB, but targetting sizes of <=10KB is recommended.
+- oversized payloads: We currently only drop pings >1MB, but targeting sizes of <=10KB is recommended.
 
 Tools
 =====
 
 Helpful tools for designing new pings include:
 
 - `gzipServer <https://github.com/mozilla/gzipServer>`_ - a Python script that can run locally and receives and saves Telemetry pings. Making Firefox send to it allows inspecting outgoing pings easily.
 - ``about:telemetry`` - allows inspecting submitted pings from the local archive, including all custom ones.
 
 Designing custom pings
 ======================
 
 In general, creating a new custom ping means you don't benefit automatically from the existing tooling. Further work is needed to make data show up in re:dash or other analysis tools.
 
-In addition to the `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection>`_, questions to guide a new pings design are:
+In addition to the `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection>`_, questions to guide a new ping design are:
 
 - Submission interval & triggers:
    - What events trigger ping submission?
    - What interval is the ping submitted in?
    - Is there a throttling mechanism?
    - What is the desired latency? (submitting "at least daily" still leads to certain latency tails)
    - Are pings submitted on a clock schedule? Or based on "time since session start", "time since last ping" etc.? (I.e. will we get sharp spikes in submission volume?)
 - Size and volume:
@@ -69,10 +69,10 @@ In addition to the `data collection revi
    - Does it need to be opt-out?
    - Does it need to be in a separate ping? (why can’t the data live in probes?)
 - Privacy:
    - Is there risk to leak PII?
    - How is that risk mitigated?
 - Data contents:
    - Does the submitted data answer the posed product questions?
    - Does the shape of the data allow to answer the questions efficiently?
-   - Is the data limited to whats needed to answer the questions?
+   - Is the data limited to what's needed to answer the questions?
    - Does the data use common formats? (i.e. can we re-use tooling or analysis know-how)

--- a/toolkit/components/telemetry/docs/collection/events.rst
+++ b/toolkit/components/telemetry/docs/collection/events.rst
@@ -6,17 +6,17 @@ Events
 
 Across the different Firefox initiatives, there is a common need for a mechanism for recording, storing, sending & analysing application usage in an event-oriented format.
 *Event Telemetry* specifies a common events dataformat, which allows for broader, shared usage of data processing tools.
 
 For events recorded into Firefox Telemetry we also provide an API that opaquely handles storage and submission to our servers.
 
 .. important::
 
-    Every new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for :bsmedberg or one of the other data peers. We try to reply within a business day.
+    Every new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for one of the data peers. We try to reply within a business day.
 
 Serialization format
 ====================
 
 Events are submitted as an array, e.g.:
 
 .. code-block:: js
 
@@ -35,18 +35,18 @@ Each event is of the form:
 .. code-block:: js
 
   [timestamp, category, method, object, value, extra]
 
 Where the individual fields are:
 
 - ``timestamp``: ``Number``, positive integer. This is the time in ms when the event was recorded, relative to the main process start time.
 - ``category``: ``String``, identifier. The category is a group name for events and helps to avoid name conflicts.
-- ``method``: ``String``, identifier. This describes the type of event that occured, e.g. ``click``, ``keydown`` or ``focus``.
-- ``object``: ``String``, identifier. This is the object the event occured on, e.g. ``reload_button`` or ``urlbar``.
+- ``method``: ``String``, identifier. This describes the type of event that occurred, e.g. ``click``, ``keydown`` or ``focus``.
+- ``object``: ``String``, identifier. This is the object the event occurred on, e.g. ``reload_button`` or ``urlbar``.
 - ``value``: ``String``, optional, may be ``null``. This is a user defined value, providing context for the event.
 - ``extra``: ``Object``, optional, may be ``null``. This is an object of the form ``{"key": "value", ...}``, both keys and values need to be strings. This is used for events where additional richer context is needed.
 
 .. _eventlimits:
 
 Limits
 ------
 
@@ -103,17 +103,17 @@ The following event properties are valid
 - ``record_in_processes`` *(required, list of strings)*: A list of processes the event can be recorded in. Currently supported values are:
 
   - ``main``
   - ``content``
   - ``gpu``
   - ``all_child`` (record in all the child processes)
   - ``all`` (record in all the processes).
 
-- ``bug_numbers`` *(required, list of numbers)*: A list of bugzilla bug numbers that are relevant to this event.
+- ``bug_numbers`` *(required, list of numbers)*: A list of Bugzilla bug numbers that are relevant to this event.
 - ``notification_emails`` *(required, list of strings)*: A list of emails of owners for this event. This is used for contact for data reviews and potentially to email alerts.
 - expiry: There are two properties that can specify expiry, at least one needs to be set:
 
   - ``expiry_version`` *(string)*: The version number in which the event expires, e.g. ``"50"``, or ``"never"``. A version number of type "N" and "N.0" is automatically converted to "N.0a1" in order to expire the event also in the development channels. For events that never expire the value ``never`` can be used.
   - ``expiry_date`` *(date)*: A date of the format ``2014-01-28``. If the local client clock reaches this date, the event will expire and not be recorded.
 
 - ``extra_keys`` *(optional, object)*: An object that specifies valid keys for the ``extra`` argument and a description - see the example above.
 
@@ -127,18 +127,18 @@ Public JS API
 ~~~~~~~~~~~~~~~~~
 
 .. code-block:: js
 
   Services.telemetry.recordEvent(category, method, object, value, extra);
 
 Record a registered event.
 
-* ``value``: Optional, may be ``null``. A string value, limitted to 80 bytes.
-* ``extra``: Optional. An object with string keys & values. Key strings are limitted to what was registered. Value strings are limitted to 80 bytes.
+* ``value``: Optional, may be ``null``. A string value, limited to 80 bytes.
+* ``extra``: Optional. An object with string keys & values. Key strings are limited to what was registered. Value strings are limited to 80 bytes.
 
 Throws if the combination of ``category``, ``method`` and ``object`` is unknown.
 Recording an expired event will not throw, but print a warning into the browser console.
 
 .. warning::
 
   Event Telemetry recording is designed to be cheap, not free. If you wish to record events in a performance-sensitive piece of code, store the events locally and record them only after the performance-sensitive piece ("hot path") has completed.
 
@@ -157,17 +157,17 @@ Example:
 
 ``setEventRecordingEnabled()``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: js
 
   Services.telemetry.setEventRecordingEnabled(category, enabled);
 
-Event recording is currently disabled by default. Privileged addons and Firefox code can enable & disable recording events for specific categories using this function.
+Event recording is currently disabled by default. Privileged add-ons and Firefox code can enable & disable recording events for specific categories using this function.
 
 Example:
 
 .. code-block:: js
 
   Services.telemetry.setEventRecordingEnabled("ui", true);
   // ... now events in the "ui" category will be recorded.
   Services.telemetry.setEventRecordingEnabled("ui", false);

--- a/toolkit/components/telemetry/docs/collection/histograms.rst
+++ b/toolkit/components/telemetry/docs/collection/histograms.rst
@@ -1,35 +1,35 @@
 ==========
 Histograms
 ==========
 
 If a user has opted into submitting performance data to Mozilla, the Telemetry system will collect various measures of Firefox performance, hardware, usage and customizations and submit it to Mozilla. The Telemetry data collected by a single client can be examined from the integrated ``about:telemetry`` browser page, while the aggregated reports across entire user populations are publicly available at `telemetry.mozilla.org <https://telemetry.mozilla.org>`_.
 
 .. important::
 
-    Every new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for :bsmedberg or one of the other data peers. We try to reply within a business day.
+    Every new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for one of the data peers. We try to reply within a business day.
 
 The following sections explain how to add a new measurement to Telemetry.
 
 Overview
 ========
 
 Telemetry histograms are an efficient way to collect numeric measurements like multiple counts or timings.
 They are collected through a common API and automatically submitted with the :doc:`main ping <../data/main-ping>`.
 
 .. hint::
 
-    Before adding a new histogram,  you should consider using other collection mechanisms. For example, if the need is to track a single scalar value (e.g. number, boolean or string), you should use :doc:`scalars`.
+    Before adding a new histogram, you should consider using other collection mechanisms. For example, if the need is to track a single scalar value (e.g. number, boolean or string), you should use :doc:`scalars`.
 
 The histogram below is taken from Firefox's ``about:telemetry`` page. It shows a histogram used for tracking plugin shutdown times and the data collected over a single Firefox session. The timing data is grouped into buckets where the height of the blue bars represents the number of items in each bucket. The tallest bar, for example, indicates that there were 63 plugin shutdowns lasting between 129ms and 204ms.
 
 .. image:: sampleHistogram.png
 
-The histograms on the ``about:telemetry`` page only show the non-empty buckets in a histogram except for the bucket to the left of the first non-empty bucket and the bucket to the right of the last non-empty bucket.
+The histograms on the ``about:telemetry`` page only show the non-empty buckets in a histogram, except for the bucket to the left of the first non-empty bucket and the bucket to the right of the last non-empty bucket.
 
 .. _choosing-histogram-type:
 
 Choosing a Histogram Type
 =========================
 
 The first step to adding a new histogram is to choose the histogram type that best represents the data being measured. The sample histogram used above is an "exponential" histogram.
 
@@ -193,17 +193,17 @@ Optional. This is one of:
 * ``"opt-in"``: (default value) This histogram is submitted by default on pre-release channels; on the release channel only if the user opted into additional data collection
 * ``"opt-out"``: this histogram is submitted by default on release and pre-release channels, unless the user opted out.
 
 .. warning::
 
     Because they are collected by default, opt-out probes need to meet a higher "user benefit" threshold than opt-in probes.
 
 
-    **Every** new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for :bsmedberg or one of the other data peers.
+    **Every** new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for one of the data peers.
 
 Changing a histogram
 ====================
 Changing histogram declarations after the histogram has been released is tricky. The current recommended procedure is to change the name of the histogram.
 
 * When changing existing histograms, the recommended pattern is to use a versioned name (``PROBE``, ``PROBE_2``, ``PROBE_3``, ...).
 * For enum histograms, it's recommended to set "n_buckets" to a slightly larger value than needed since new elements may be added to the enum in the future.
 

--- a/toolkit/components/telemetry/docs/collection/index.rst
+++ b/toolkit/components/telemetry/docs/collection/index.rst
@@ -10,17 +10,17 @@ In cases where this isn't possible and m
 
 *Note:* Every new data collection must go through a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection>`_.
 
 The current data collection possibilities include:
 
 * :doc:`scalars` allow recording of a single value (string, boolean, a number)
 * :doc:`histograms` can efficiently record multiple data points
 * ``environment`` data records information about the system and settings a session occurs in
-* :doc:`events` can record richer data on individual occurences of specific actions
+* :doc:`events` can record richer data on individual occurrences of specific actions
 * ``TelemetryLog`` allows collecting ordered event entries up to a limit of 1000 entries (note: this does not have supporting analysis tools)
 * :doc:`measuring elapsed time <measuring-time>`
 * :doc:`custom pings <custom-pings>`
 * :doc:`stack capture <stack-capture>` allow recording application call stacks
 * :doc:`Use counters <use-counters>` measure the usage of web platform features
 * :doc:`Experiment annotations <experiments>`
 * :doc:`Remote content uptake <uptake>`
 

--- a/toolkit/components/telemetry/docs/collection/measuring-time.rst
+++ b/toolkit/components/telemetry/docs/collection/measuring-time.rst
@@ -13,25 +13,25 @@ JavaScript can measure elapsed time usin
 
 API:
 
 .. code-block:: js
 
     TelemetryStopwatch = {
       // Start, check if running, cancel & finish recording elapsed time into a
       // histogram.
-      // |aObject| is optional. If specificied, the timer is associated with this
+      // |aObject| is optional. If specified, the timer is associated with this
       // object, so multiple time measurements can be done concurrently.
       start(histogramId, aObject);
       running(histogramId, aObject);
       cancel(histogramId, aObject);
       finish(histogramId, aObject);
       // Start, check if running, cancel & finish recording elapsed time into a
       // keyed histogram.
-      // |key| specificies the key to record into.
+      // |key| specifies the key to record into.
       // |aObject| is optional and used as above.
       startKeyed(histogramId, key, aObject);
       runningKeyed(histogramId, key, aObject);
       cancelKeyed(histogramId, key, aObject);
       finishKeyed(histogramId, key, aObject);
     };
 
 Example:
@@ -53,17 +53,17 @@ Example:
     if (!TelemetryStopwatch.running("SAMPLE_FILE_LOAD_TIME_MS")) {
       TelemetryStopwatch.start("SAMPLE_FILE_LOAD_TIME_MS");
     }
 
     // Periodically, it's necessary to attempt to finish a
     // TelemetryStopwatch that's already been canceled or
     // finished. Normally, that throws a warning to the
     // console. If the TelemetryStopwatch being possibly
-    // cancelled or finished is expected behaviour, the
+    // canceled or finished is expected behaviour, the
     // warning can be suppressed by passing the optional
     // aCanceledOkay argument.
 
     // ... suppress warning on a previously finished
     // TelemetryStopwatch
     TelemetryStopwatch.finish("SAMPLE_FILE_LOAD_TIME_MS", null,
                               true /* aCanceledOkay */);
 

--- a/toolkit/components/telemetry/docs/collection/scalars.rst
+++ b/toolkit/components/telemetry/docs/collection/scalars.rst
@@ -4,17 +4,17 @@ Scalars
 
 Historically we started to overload our histogram mechanism to also collect scalar data,
 such as flag values, counts, labels and others.
 The scalar measurement types are the suggested way to collect that kind of scalar data.
 The serialized scalar data is submitted with the :doc:`main pings <../data/main-ping>`.
 
 .. important::
 
-    Every new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for :bsmedberg or one of the other data peers. We try to reply within a business day.
+    Every new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for one of the data peers. We try to reply within a business day.
 
 The API
 =======
 Scalar probes can be managed either through the `nsITelemetry interface <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/nsITelemetry.idl>`_
 or the `C++ API <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Telemetry.h>`_.
 
 JS API
 ------
@@ -131,17 +131,17 @@ Keyed Scalars
 -------------
 Keyed scalars are collections of one of the available scalar types, indexed by a string key that can contain UTF8 characters and cannot be longer than 70 characters. Keyed scalars can contain up to 100 keys. This scalar type is for example useful when you want to break down certain counts by a name, like how often searches happen with which search engine.
 
 Keyed scalars should only be used if the set of keys are not known beforehand. If the keys are from a known set of strings, other options are preferred if suitable, like categorical histograms or splitting measurements up into separate scalars.
 
 Multiple processes caveats
 --------------------------
 When recording data in different processes of the same type (e.g. multiple content processes), the user is responsible for preventing races between the operations on the scalars.
-Races can happen because scalar changes are send from each child process to the parent process, and then merged into the final storage location. Since there's no synchronization between the processes, operations like ``setMaximum`` can potentially produce different results if sent from more than one child process.
+Races can happen because scalar changes are sent from each child process to the parent process, and then merged into the final storage location. Since there's no synchronization between the processes, operations like ``setMaximum`` can potentially produce different results if sent from more than one child process.
 
 The processor scripts
 =====================
 The scalar definition file is processed and checked for correctness at compile time. If it
 conforms to the specification, the processor scripts generate two C++ headers files, included
 by the Telemetry C++ core.
 
 gen-scalar-data.py

--- a/toolkit/components/telemetry/docs/collection/stack-capture.rst
+++ b/toolkit/components/telemetry/docs/collection/stack-capture.rst
@@ -4,17 +4,17 @@ Stack capture
 
 While studying behavior of Firefox in the wild it is sometimes useful to inspect
 call stacks without causing the browser to crash. Historically we could only
 obtain stacks for inspection from crash reports. Now stacks can be captured on
 demand and annotated with a unique key for further inspection.
 
 Capturing stacks is only supported on official builds with ``--enable-profiling``
 switch enabled, such as Nightly builds, for example. The feature is available on
-Windows, Linux and OSX. Capturing stacks is only available with extended Telemetry
+Windows, Linux and macOS. Capturing stacks is only available with extended Telemetry
 enabled.
 
 Captured stacks are grouped by a user-defined key. Identical stacks captured under
 the same key are combined in order to reduce their memory footprint. A counter is
 used to reflect the frequency of identical stacks.
 
 The serialized stack data is submitted with the :doc:`main pings <../data/main-ping>`.
 

--- a/toolkit/components/telemetry/docs/collection/uptake.rst
+++ b/toolkit/components/telemetry/docs/collection/uptake.rst
@@ -7,17 +7,17 @@ Firefox continuously pulls data from different remote sources (eg. settings, system add-ons, …). In order to have consistent insights about the *uptake rate* of these *update sources*, our clients can use a unified Telemetry helper to report their *update status*.
 The helper — described below — reports predefined update status, which eventually gives a unified way to obtain:
 
 * the proportion of success among clients;
 * its evolution over time;
 * the distribution of error causes.
 
 .. notes::
 
-   Examples of update sources: *remote settings, addons update, addons, gfx, and plugins blocklists, certificate revocation, certificate pinning, system addons delivery…*
+   Examples of update sources: *remote settings, add-ons update, add-ons, gfx, and plugins blocklists, certificate revocation, certificate pinning, system add-ons delivery…*
 
    Examples of update status: *up-to-date, success, network error, server error, signature error, server backoff, unknown error…*
 
 
 Usage
 -----
 
 .. code-block:: js

--- a/toolkit/components/telemetry/docs/concepts/pings.rst
+++ b/toolkit/components/telemetry/docs/concepts/pings.rst
@@ -1,15 +1,15 @@
 .. _telemetry_pings:
 
 =====================
 Telemetry pings
 =====================
 
-A *Telemetry ping* is the data that we send to Mozillas Telemetry servers.
+A *Telemetry ping* is the data that we send to Mozilla's Telemetry servers.
 
 That data is stored as a JSON object client-side and contains common information to all pings and a payload specific to a certain *ping types*.
 
 The top-level structure is defined by the :doc:`common ping format <../data/common-ping>` format.
 It contains:
 
 * some basic information shared between different ping types
 * the :doc:`environment data <../data/environment>` (optional)

--- a/toolkit/components/telemetry/docs/concepts/sessions.rst
+++ b/toolkit/components/telemetry/docs/concepts/sessions.rst
@@ -1,23 +1,23 @@
 ========
 Sessions
 ========
 
-A *session* is the time from when Firefox starts until it shut down.
+A *session* is the time from when Firefox starts until it shuts down.
 A session can be very long-running. E.g. for Mac users that are used to always put their laptops into sleep-mode, Firefox may run for weeks.
 We slice the sessions into smaller logical units called *subsessions*.
 
 Subsessions
 ===========
 
 The first subsession starts when the browser starts. After that, we split the subsession for different reasons:
 
 * ``daily``, when crossing local midnight. This keeps latency acceptable by triggering a ping at least daily for most active users.
-* ``environment-change``, when a change to the *environment* happens. This happens for important changes to the Firefox settings and when addons activate or deactivate.
+* ``environment-change``, when a change to the *environment* happens. This happens for important changes to the Firefox settings and when add-ons activate or deactivate.
 
 On a subsession split, a :doc:`main ping <../data/main-ping>` with that reason will be submitted. We store the reason in the pings payload, to see what triggered it.
 
 A session always ends with a subsession with one of two reason:
 
 * ``shutdown``, when the browser was cleanly shut down. To avoid delaying shutdown, we only save this ping to disk and send it at the next opportunity (typically the next browsing session).
 * ``aborted-session``, when the browser crashed. While Firefox is active, we write the current ``main`` ping data to disk every 5 minutes. If the browser crashes, we find this data on disk on the next start and send it with this reason.
 
@@ -29,12 +29,9 @@ Subsession data
 A subsessions data consists of:
 
 * general information: the date the subsession started, how long it lasted, etc.
 * specific measurements: histogram & scalar data, etc.
 
 This has some advantages:
 
 * Latency - Sending a ping with all the data of a subsession immediately after it ends means we get the data from installs faster. For ``main`` pings, we aim to send a ping at least daily by starting a new subsession at local midnight.
-* Correlation - By starting new subsessions when fundamental settings change (i.e. changes to the *environment*), we can correlate a subsessions data better to those settings.
-
-
-
+* Correlation - By starting new subsessions when fundamental settings change (i.e. changes to the *environment*), we can better correlate a subsession's data to those settings.

--- a/toolkit/components/telemetry/docs/data/environment.rst
+++ b/toolkit/components/telemetry/docs/data/environment.rst
@@ -8,17 +8,17 @@ Changes to most of these data points are
 The environment data may also be submitted by other ping types.
 
 *Note:* This is not submitted with all ping types due to privacy concerns. This and other data is inspected under the `data collection policy <https://wiki.mozilla.org/Firefox/Data_Collection>`_.
 
 Some parts of the environment must be fetched asynchronously at startup. We don't want other Telemetry components to block on waiting for the environment, so some items may be missing from it until the async fetching finished.
 This currently affects the following sections:
 
 - profile
-- addons
+- add-ons
 
 
 Structure:
 
 .. code-block:: js
 
     {
       build: {
@@ -200,17 +200,17 @@ Structure:
               },
               advancedLayers: { // Advanced Layers compositing. Only present if D3D11 enabled.
                 status: <string>,    // See the status codes above.
               },
             },
           },
       },
       addons: {
-        activeAddons: { // the currently enabled addons
+        activeAddons: { // the currently enabled add-ons
           <addon id>: {
             blocklisted: <bool>,
             description: <string>, // null if not available
             name: <string>,
             userDisabled: <bool>,
             appDisabled: <bool>,
             version: <string>,
             scope: <integer>,
@@ -395,13 +395,13 @@ This object contains operating system in
 addons
 ------
 
 activeAddons
 ~~~~~~~~~~~~
 
 Starting from Firefox 44, the length of the following string fields: ``name``, ``description`` and ``version`` is limited to 100 characters. The same limitation applies to the same fields in ``theme`` and ``activePlugins``.
 
-Some of the fields in the record for each addon are not available during startup.  The fields that will always be present are ``id``, ``version``, ``type``, ``updateDate``, ``scope``, ``isSystem``, ``isWebExtension``, and ``multiprocessCompatible``.  All the other fields documented above become present shortly after the ``sessionstore-windows-restored`` event is dispatched.
+Some of the fields in the record for each add-on are not available during startup.  The fields that will always be present are ``id``, ``version``, ``type``, ``updateDate``, ``scope``, ``isSystem``, ``isWebExtension``, and ``multiprocessCompatible``.  All the other fields documented above become present shortly after the ``sessionstore-windows-restored`` event is dispatched.
 
 experiments
 -----------
 For each experiment we collect the ``id`` and the ``branch`` the client is enrolled in. Both fields are truncated to 100 characters and a warning is printed when that happens. This section will eventually supersede ``addons/activeExperiment``.

--- a/toolkit/components/telemetry/docs/data/main-ping.rst
+++ b/toolkit/components/telemetry/docs/data/main-ping.rst
@@ -85,17 +85,17 @@ The length of the current session so far
 This uses a monotonic clock, so this may mismatch with other measurements that
 are not monotonic like calculations based on ``Date.now()``.
 
 If the monotonic clock failed, this will be ``-1``.
 
 Note that this currently does not behave consistently over our supported platforms:
 
 * On Windows this uses ``GetTickCount64()``, which does increase over sleep periods
-* On OS X this uses ``mach_absolute_time()``, which does not increase over sleep periods
+* On macOS this uses ``mach_absolute_time()``, which does not increase over sleep periods
 * On POSIX/Linux this uses ``clock_gettime(CLOCK_MONOTONIC, &ts)``, which should not increase over sleep time
 
 See `bug 1204823 <https://bugzilla.mozilla.org/show_bug.cgi?id=1204823>`_ for details.
 
 subsessionLength
 ~~~~~~~~~~~~~~~~
 The length of this subsession in seconds.
 This uses a monotonic clock, so this may mismatch with other measurements that are not monotonic (e.g. based on ``Date.now()``).
@@ -144,17 +144,17 @@ This section contains the :doc:`../colle
 events
 ~~~~~~
 This section contains the :ref:`eventtelemetry` that are recorded for the current subsession. Events are not always recorded, recording has to be enabled first for the Firefox session.
 
 The recorded events are defined in the `Events.yaml <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Events.yaml>`_. The ``info.revision`` field indicates the revision of the file that describes the reported events.
 
 childPayloads
 -------------
-The Telemetry payloads sent by child processes, recorded on child process shutdown (event ``content-child-shutdown`` observed). They are reduced session payloads, only available with e10s. Among some other things, they don't contain histograms, keyed histograms, addon details, or UI Telemetry.
+The Telemetry payloads sent by child processes, recorded on child process shutdown (event ``content-child-shutdown`` observed). They are reduced session payloads, only available with e10s. Among some other things, they don't contain histograms, keyed histograms, add-on details, or UI Telemetry.
 
 Note: Child payloads are not collected and cleared with subsession splits, they are currently only meaningful when analysed from ``saved-session`` or ``main`` pings with ``reason`` set to ``shutdown``.
 
 Note: Before Firefox 51 and bug 1218576, content process histograms and keyedHistograms were in the individual child payloads instead of being aggregated into ``processes.content``.
 
 simpleMeasurements
 ------------------
 This section contains a list of simple measurements, or counters. In addition to the ones highlighted below, Telemetry timestamps (see `here <https://dxr.mozilla.org/mozilla-central/search?q=%22TelemetryTimestamps.add%22&redirect=false&case=true>`_ and `here <https://dxr.mozilla.org/mozilla-central/search?q=%22recordTimestamp%22&redirect=false&case=true>`_) can be reported.
@@ -602,17 +602,17 @@ Structure:
           ... other frames ...
          ],
          ... other stacks ...
       ],
     },
 
 addonDetails
 ------------
-This section contains per-addon telemetry details, as reported by each addon provider. The XPI provider is the only one reporting at the time of writing (`see DXR <https://dxr.mozilla.org/mozilla-central/search?q=setTelemetryDetails&case=true>`_). Telemetry does not manipulate or enforce a specific format for the supplied provider's data.
+This section contains per add-on telemetry details, as reported by each add-on provider. The XPI provider is the only one reporting at the time of writing (`see DXR <https://dxr.mozilla.org/mozilla-central/search?q=setTelemetryDetails&case=true>`_). Telemetry does not manipulate or enforce a specific format for the supplied provider's data.
 
 Structure:
 
 .. code-block:: js
 
     "addonDetails": {
       "XPI": {
         "adbhelper@mozilla.org": {

--- a/toolkit/components/telemetry/docs/data/sync-ping.rst
+++ b/toolkit/components/telemetry/docs/data/sync-ping.rst
@@ -18,23 +18,23 @@ Structure:
       ... common ping data
       payload: {
         version: 1,
         os : { ... }, // os data from the current telemetry environment. OS specific, but typically includes name, version and locale.
         discarded: <integer count> // Number of syncs discarded -- left out if zero.
         why: <string>, // Why did we submit the ping? Either "shutdown", "schedule", or "idchanged".
         uid: <string>, // Hashed FxA unique ID, or string of 32 zeros. If this changes between syncs, the payload is submitted.
         deviceID: <string>, // Hashed FxA Device ID, hex string of 64 characters, not included if the user is not logged in. If this changes between syncs, the payload is submitted.
-        sessionStartDate: <ISO date>, // hourly precision, ISO date in local time
+        sessionStartDate: <ISO date>, // Hourly precision, ISO date in local time
         // Array of recorded syncs. The ping is not submitted if this would be empty
         syncs: [{
           when: <integer milliseconds since epoch>,
           took: <integer duration in milliseconds>,
           didLogin: <bool>, // Optional, is this the first sync after login? Excluded if we don't know.
-          why: <string>, // Optional, why the sync occured, excluded if we don't know.
+          why: <string>, // Optional, why the sync occurred, excluded if we don't know.
 
           // Optional, excluded if there was no error.
           failureReason: {
             name: <string>, // "httperror", "networkerror", "shutdownerror", etc.
             code: <integer>, // Only present for "httperror" and "networkerror".
             error: <string>, // Only present for "othererror" and "unexpectederror".
             from: <string>, // Optional, and only present for "autherror".
           },
@@ -107,27 +107,27 @@ Structure:
     }
 
 info
 ----
 
 discarded
 ~~~~~~~~~
 
-The ping may only contain a certain number of entries in the ``"syncs"`` array, currently 500 (it is determined by the ``"services.sync.telemetry.maxPayloadCount"`` preference).  Entries beyond this are discarded, and recorded in the discarded count.
+The ping may only contain a certain number of entries in the ``"syncs"`` array, currently 500 (it is determined by the ``"services.sync.telemetry.maxPayloadCount"`` preference). Entries beyond this are discarded, and recorded in the discarded count.
 
 syncs.took
 ~~~~~~~~~~
 
-These values should be monotonic.  If we can't get a monotonic timestamp, -1 will be reported on the payload, and the values will be omitted from the engines. Additionally, the value will be omitted from an engine if it would be 0 (either due to timer inaccuracy or finishing instantaneously).
+These values should be monotonic. If we can't get a monotonic timestamp, -1 will be reported on the payload, and the values will be omitted from the engines. Additionally, the value will be omitted from an engine if it would be 0 (either due to timer inaccuracy or finishing instantaneously).
 
 uid
 ~~~~~~~~~
 
-This property containing a hash of the FxA account identifier, which is a 32 character hexidecimal string.  In the case that we are unable to authenticate with FxA and have never authenticated in the past, it will be a placeholder string consisting of 32 repeated ``0`` characters.
+This property containing a hash of the FxA account identifier, which is a 32 character hexidecimal string. In the case that we are unable to authenticate with FxA and have never authenticated in the past, it will be a placeholder string consisting of 32 repeated ``0`` characters.
 
 syncs.why
 ~~~~~~~~~
 
 One of the following values:
 
 - ``startup``: This is the first sync triggered after browser startup.
 - ``schedule``: This is a sync triggered because it has been too long since the last sync.

--- a/toolkit/components/telemetry/docs/data/update-ping.rst
+++ b/toolkit/components/telemetry/docs/data/update-ping.rst
@@ -32,43 +32,43 @@ This field supports the following values
 - ``success`` the ping was generated after the browser was restarted and the update correctly applied.
 
 payload.targetChannel
 -----------------------
 The Firefox channel the update was fetched from (only valid for pings with reason "ready").
 
 payload.targetVersion
 -----------------------
-The Firefox version the browser is updating to. Follows the same format a application.version (only valid for pings with reason "ready").
+The Firefox version the browser is updating to. Follows the same format as application.version (only valid for pings with reason "ready").
 
 payload.targetBuildId
 -----------------------
-The Firefox build id the browser is updating to. Follows the same format a application.buildId (only valid for pings with reason "ready").
+The Firefox build id the browser is updating to. Follows the same format as application.buildId (only valid for pings with reason "ready").
 
 payload.previousChannel
 -----------------------
 The Firefox channel the profile was on before the update was applied (only valid for pings with reason "success").
 This can be ``null``.
 
 payload.previousVersion
 -----------------------
-The Firefox version the browser is updating from. Follows the same format a application.version (only valid for pings with reason "success").
+The Firefox version the browser is updating from. Follows the same format as application.version (only valid for pings with reason "success").
 
 payload.previousBuildId
 -----------------------
-The Firefox build id the browser is updating from. Follows the same format a application.buildId (only valid for pings with reason "success").
+The Firefox build id the browser is updating from. Follows the same format as application.buildId (only valid for pings with reason "success").
 
 Expected behaviours
 -------------------
 The following is a list of conditions and expected behaviours for the ``update`` ping:
 
 - **The ping is generated once every time an update is downloaded, after it was verified:**
 
   - *for users who saw the privacy policy*, the ``update`` ping is sent immediately;
-  - *for users who did not see the privacy policy*, the ``update`` ping is saved to disk and after the policy is displayed.
-- **If the download of the update retries or other fallback occur**: the ``update`` ping will not be generated
+  - *for users who did not see the privacy policy*, the ``update`` ping is saved to disk and sent after the policy is displayed.
+- **If the download of the update retries or other fallback occurs**: the ``update`` ping will not be generated
   multiple times, but only one time once the download is complete and verified.
 - **If automatic updates are disabled**: when the user forces a manual update, no ``update`` ping will be generated.
 - **If updates fail to apply**: in some cases the client will download the same update blob and generate a new ``update`` ping for the same target version and build id, with a different document id.
 - **If the build update channel contains the CCK keyword**, the update ping will not report it but rather report a vanilla channel name (e.g. ``mozilla-cck-test-beta`` gets reported as ``beta``).
 - **If a profile refresh occurs before the update is applied**, the update ping with ``reason = success`` will not be generated.
 - **If the update is applied on a new profile, different then the one it was downloaded in**, the update ping with ``reason = success`` will not be generated.
 - **If a newer browser version is installed over an older**, the update ping with ``reason = success`` will not be generated.
\ No newline at end of file

--- a/toolkit/components/telemetry/docs/fhr/dataformat.rst
+++ b/toolkit/components/telemetry/docs/fhr/dataformat.rst
@@ -822,17 +822,17 @@ Notes
 ^^^^^
 
 All of the properties appear in the *last* section except for
 *isDefaultBrowser*, which appears under *days*.
 
 Example
 ^^^^^^^
 
-This example comes from an official OS X Nightly build::
+This example comes from an official macOS Nightly build::
 
     "org.mozilla.appInfo.appinfo": {
       "_v": 1,
       "appBuildID": "20130311030946",
       "distributionID": "",
       "distributionVersion": "",
       "hotfixVersion": "",
       "id": "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}",
@@ -1348,17 +1348,17 @@ downloadAttempts
 downloadFailures
     Integer count of times a download supposedly completed but couldn't
     be validated. This likely represents something wrong with the network
     connection. The ratio of this to ``downloadAttempts`` should be low.
 
 installAttempts
     Integer count of times the hotfix attempted to run the installer.
     This should ideally be 1. It should only be greater than 1 if UAC
-    elevation was cancelled or not allowed.
+    elevation was canceled or not allowed.
 
 installFailures
     Integer count of total installation failures this client experienced.
     Can be 0. ``installAttempts - installFailures`` implies install successes.
 
 notificationsShown
     Integer count of times a notification was displayed to the user that
     they are running an older Firefox.

--- a/toolkit/components/telemetry/docs/internals/pingsender.rst
+++ b/toolkit/components/telemetry/docs/internals/pingsender.rst
@@ -23,14 +23,14 @@ additional headers:
 .. note::
 
   The ping sender relies on libcurl for Linux and Mac build and on WinInet for
   Windows ones for its HTTP functionality. It currently ignores Firefox or the
   system proxy configuration.
 
 In non-debug mode the ping sender doesn't print anything, not even on error,
 this is done deliberately to prevent startling the user on architectures such
-as Windows that would open a seperate console window just to display the
+as Windows that would open a separate console window just to display the
 program output. If you need runtime information to be printed out compile the
 ping sender with debugging enabled.
 
 The pingsender is not supported on Firefox for Android at the moment
 (see `bug 1335917 <https://bugzilla.mozilla.org/show_bug.cgi?id=1335917>`_)