fix: fixing errors in documentation (#2728)

Co-authored-by: Louis-Maxime Crédeville <louis-maxime.credeville@gleamer.ai>
2022-03-03 11:28:07 -05:00
1 parent 6c9b5ca10c
commit fe9e7123d7
@@ -11,7 +11,7 @@ possible use cases and decided to significantly change and improve the
 architecture.

 Below, we aim to demystify that complexity by providing insight into how
-`OHIF Platform` is architected, and the role each of it's dependent libraries
+`OHIF Platform` is architected, and the role each of its dependent libraries
 plays.

 ## Overview
@@ -46,7 +46,7 @@ you'll see the following:
 └── README.md
 ```

-OHIF v3 is comprised of the following components, described in detail in further
+OHIF v3 is composed of the following components, described in detail in further
 sections:

 - `@ohif/viewer`: The core framework that controls extension registration, mode
@@ -62,7 +62,7 @@ sections:

 ## Extensions

-The `extensions` directory contains many packages that provides essential
+The `extensions` directory contains many packages that provide essential
 functionalities such as rendering, study/series browsers, measurement tracking
 that modes can consume to enable a certain workflow. Extensions have had their
 behavior changed in `OHIF-v3` and their api is expanded. In summary:
@@ -183,7 +183,7 @@ you would need to recreate.

 This is a great question. Modes are designed to consume extensions, so you
 should implement your functionality in one of the modules of your new extension,
-and let the mode to consume it. This way, in future, if you needed another mode
+and let the mode consume it. This way, in the future, if you needed another mode
 that utilizes the same functionality, you can easily hook the extension to the
 new mode as well.

@@ -15,7 +15,7 @@ we make to the OHIF Viewer, then follow these steps:
 - [Fork][fork-a-repo] the [OHIF/Viewers][ohif-viewers-repo] repository
 - [Create a local clone][clone-a-repo] of your fork
  - `git clone https://github.com/YOUR-USERNAME/Viewers`
- Add OHIF/Viewers as a [remote repository][add-remote-repo] labled `upstream`
+- Add OHIF/Viewers as a [remote repository][add-remote-repo] labeled `upstream`
  - Navigate to the cloned project's directory
  - `git remote add upstream https://github.com/OHIF/Viewers.git`

@@ -33,7 +33,7 @@ first contact with would-be adopters and contributors, it's important that we
 strive for timely responses and satisfactory resolutions. We attempt to
 accomplish this by:

-1. Responding to issues requiring `triage` at least once a week
+1. Responding to issue requiring `triage` at least once a week
 2. Create new "official issues" from "community issues"
 3. Provide clear guidance and next steps (when applicable)
 4. Regularly clean up old (stale) issues
@@ -97,7 +97,7 @@ appropriate:
 We rely on GitHub Checks and integrations with third party services to evaluate
 changes in code quality and test coverage. Tests must pass and User cases must
 be present (when applicable) before a PR can be merged to master, and code
-quality and test coverage must not changed by a significant margin. For some
+quality and test coverage must not be changed by a significant margin. For some
 repositories, visual screenshot-based tests are also included, and video
 recordings of end-to-end tests are stored for later review.

@@ -50,7 +50,7 @@ For running the OHIF e2e test you need to run the following steps:

  Run the tests by clicking on the `Run #number integration tests` .

-  A new window will open and you will see e2e tests being executed one after
+  A new window will open, and you will see e2e tests being executed one after
  each other.

  ![e2e-cypress-final](../assets/img/e2e-cypress-final.png)
@@ -118,7 +118,7 @@ choice for asserting an element's border color.

 Modern tooling gives us this "for free". It can catch invalid regular
 expressions, unused variables, and guarantee we're calling methods/functions
-with the expected paramater types.
+with the expected parameter types.

 Example Tooling: