Fix typos

README.md

@@ -174,7 +174,7 @@ commandline by using the `CMAKE_ARGS` environment variable.
 
 `env CMAKE_ARGS="-DCMAKE_VAR=VALUE1 -DCMAKE_VAR_2=VALUE2" pip install .`
 
-Additionaly, to reproduce CI failures regarding the file manifest, run:
+Additionally, to reproduce CI failures regarding the file manifest, run:
 `make manifest` locally to run the python `check-manifest` program.
 
 ## C++ Coverage Builds

docs/cxx/cxx.rst

@@ -38,7 +38,7 @@ straightforward and uncontroversial.
 
 Reminder: these
 `sample header files <https://github.com/davidbaraff/OpenTimelineIO/tree/master/proposed-c%2B%2B-api/opentime>`_
-exist only to show the API; namespacing and other niceties are ommitted.
+exist only to show the API; namespacing and other niceties are omitted.
 
 Starting Examples
 +++++++++++++++++
@@ -82,7 +82,7 @@ already defines properties ``name`` and ``metadata``: ::
 	std::color _color;
     };
 
-The contructor takes four properties, two of which (``marked_range`` and
+The constructor takes four properties, two of which (``marked_range`` and
 ``color``) are stored directly in ``Marker``, with the remaining two (``name``
 and ``metadata``) handled by the base class ``SerializableObjectWithMetadata``.
 
@@ -146,7 +146,7 @@ details above as appropriate for your case.
    Properties are written to the JSON file in the order they are written
    to from within ``write_to()``.  But the reading code need not be in the same order,
    and changes in the ordering of either the reading or writing code will not
-   break compatability with previously written JSON files.
+   break compatibility with previously written JSON files.
 
    However, it is vital to invoke ``Parent::read_from()`` *after* reading all
    of the derived class properties, while for writing ``Parent::write_to()``
@@ -155,7 +155,7 @@ details above as appropriate for your case.
 .. Note::
    Also note that the order of properties within a JSON file for data
    that is essentially a ``std::map<>`` (see ``AnyDictionary`` below)
-   is always alphebetical by key.  This ensures deterministic JSON file
+   is always alphabetical by key.  This ensures deterministic JSON file
    writing which is important for comparison and testing.
 
 Using Schemas
@@ -193,7 +193,7 @@ to JSON is transported as a C++ ``any``.  What can that ``any`` hold?
 First, the ``any`` can be empty, which corresponds with a ``null`` JSON value.
 The ``any`` could also hold any of the following "atomic" types: ``bool``,
 ``int``, ``double``, ``std::string``, ``RationalTime``, ``TimeRange`` and
-``TimeTransform``.  All but the last three are immediately expressable in JSON,
+``TimeTransform``.  All but the last three are immediately expressible in JSON,
 while the three Opentime types are read/written as compound structures with the
 same format that the current Python implementation delivers.  The final
 "atomic" type that an ``any`` can hold is a ``SerializableObject*``, which
@@ -323,7 +323,7 @@ Memory Management
 +++++++++++++++++
 
 The final topic we must deal with is memory management. Languages like Python
-and Swift natually make use of reference counted class instances. We considered
+and Swift naturally make use of reference counted class instances. We considered
 such a route in C++, by requiring that manipulations be done not in terms of
 ``SerializableObject*`` pointers, but rather using
 ``std::shared_ptr<SerializableObject>`` (and the corresponding
@@ -679,7 +679,7 @@ What makes this complicated is the following set of rules/constraints:
     virtue of a Python wrapper instance P being constructed from Python.  Until that C++ object X
     is passed to C++ in some way, then X will exist only as long as P does.
 
-How can we satisfy all these contraints, while ensuring we don't create retain
+How can we satisfy all these constraints, while ensuring we don't create retain
 cycles (which might be fixable with Python garbage collection, but also
 might not)?  Here is the solution we came up with; if you have an alternate
 suggestion, we would be happy to hear it.

docs/tutorials/adapters.md

@@ -12,7 +12,7 @@ The OpenTimelineIO native file format adapters that are present in the `opentime
 
 ## Batteries-Included Adapters
 
-To also install a curated list of additional useful adapters, use the [OpenTimelineIO-Plugins ](https://pypi.org/project/OpenTimelineIO-Plugins/) python package. In addition to the OpenTimelineIO native adapters, you'll get aditional useful adapters including:
+To also install a curated list of additional useful adapters, use the [OpenTimelineIO-Plugins ](https://pypi.org/project/OpenTimelineIO-Plugins/) python package. In addition to the OpenTimelineIO native adapters, you'll get additional useful adapters including:
 
 - [AAF](https://github.com/OpenTimelineIO/otio-aaf-adapter)
 - [ale](https://github.com/OpenTimelineIO/otio-ale-adapter)

docs/tutorials/contributing.md

@@ -19,7 +19,7 @@ Here are the two possible CLAs:
 Please follow the coding convention and style in each file and in each library when adding new files.
 
 ## Platform Support Policy
-As recomended by the [VFX Platform](https://vfxplatform.com) (see "Support Guidance"), we support the intended calendar year of the release as well as the three prior years.
+As recommended by the [VFX Platform](https://vfxplatform.com) (see "Support Guidance"), we support the intended calendar year of the release as well as the three prior years.
 
 ## Git Workflow
 Here is the workflow we recommend for working on OpenTimelineIO if you intend on contributing changes back:

docs/tutorials/otio-filebundles.md

@@ -62,7 +62,7 @@ When a bundle is read from disk using the OpenTimelineIO Python API (using the a
 
 For example, to view the timeline (not the media) of an otioz file in `otioview`, you can run:
 
-`otioview sommething.otioz`
+`otioview something.otioz`
 
 Because this will _only_ read the `content.otio` from the bundle, it is usually a fast operation to run. None of the media is decoded or unzipped during this process.