Fixed typos and punctuation

Signed-off-by: Jana Rangasamy <[email protected]>

docs/architecture.md

@@ -81,7 +81,7 @@ This layer represents a set of **Rust APIs** that provide some core functionalit
 
 It's composed of two modules:
 
-- **linter:** this module implements the core linting functionality of CLOMonitor. All checks currently run by CLOMonitor are handled by this module, and both the `CLI tool` and the `tracker` rely on it. The linter is able to run multiple `check sets` on each repository. Each `check set` defines a number of checks that will be run on the repository. For more details about what checks are run on each `check set` please see the [checks documentation](https://github.com/cncf/clomonitor/blob/main/docs/checks.md).
+- **linter:** this module implements the core linting functionality of CLOMonitor. All checks currently run by CLOMonitor are handled by this module, and both the `CLI tool` and the `tracker` rely on it. The linter is able to run multiple `check sets` on each repository. Each `check set` defines a number of checks that will be run on the repository. For more details about what checks are run on each `check set`, please see the [checks documentation](https://github.com/cncf/clomonitor/blob/main/docs/checks.md).
 
 - **score:** this module is in charge of scoring reports produced by the linter. The linter will produce different reports for each of the kinds supported, and each of the reports will be scored differently as well. In addition to the reports' scoring functionality, this module provides some score related features as well, like rating a given score or merging multiple scores.
 

docs/checks.md

@@ -2,7 +2,7 @@
 
 **CLOMonitor** runs sets of checks periodically on all the repositories registered in the database. These checks are run *every hour*, provided the repository has changed since the last time it was checked. In the case of repositories that don't change often, we make sure that they are checked at least *once a day* anyway. This way we keep reports up to date with the latest checks additions and improvements.
 
-Checks are organized in `check sets`. Each `check set` defines a number of checks that will be run on the repository and one or more `check sets` can be applied to a single repository. At the moment the following sets are supported: `code`, `code-lite`, `community` and `docs`. The set of checks run for each one are as follows:
+Checks are organized in `check sets`. Each `check set` defines a number of checks that will be run on the repository and one or more `check sets` can be applied to a single repository. At the moment, the following sets are supported: `code`, `code-lite`, `community` and `docs`. The set of checks run for each one are as follows:
 
 - **code** (recommended for projects' primary code repository)
 
@@ -65,7 +65,7 @@ Checks are organized in `check sets`. Each `check set` defines a number of check
 
 Many checks rely on checking that certain files exists on a given path. Even though most of these checks support a number of variants, sometimes this won't work for some projects that may be using a different repository layout. In those cases, the recommended approach is to add a section to the `README` file of the repository pointing users to the document location. This will help users discovering this information and will make CLOMonitor happy :) At the moment we support detecting headers as well as links in `README` files that follow some patterns. Please see the reference below for more information on each case. Some projects have already proceeded this way successfully: [Kubernetes clomonitor PR](https://github.com/kubernetes/kubernetes/pull/108110), [KEDA clomonitor PR](https://github.com/kedacore/keda/pull/2704) and [Cilium clomonitor PR](https://github.com/cilium/cilium/pull/19037).
 
-For more details about how each of the checks are performed, please see the reference below. Note that **CLOMonitor** does not follow symlinks when reading files content. If you find that any of the checks isn't working as expected or you have ideas about how to improve them please [file an issue](https://github.com/cncf/clomonitor/issues) or [open a discussion](https://github.com/cncf/clomonitor/discussions) in GitHub.
+For more details about how each of the checks are performed, please see the reference below. Note that **CLOMonitor** does not follow symlinks when reading files content. If you find that any of the checks isn't working as expected or you have ideas about how to improve them, please [file an issue](https://github.com/cncf/clomonitor/issues) or [open a discussion](https://github.com/cncf/clomonitor/discussions) in GitHub.
 
 ## Exemptions
 
@@ -467,7 +467,7 @@ This check passes if:
 
 **ID**: `openssf_scorecard_badge`
 
-Scorecard assesses open source projects for security risks through a series of automated checks. For more information about the Scorecard badge please see <https://github.com/marketplace/actions/ossf-scorecard-action#scorecard-badge>.
+Scorecard assesses open source projects for security risks through a series of automated checks. For more information about the Scorecard badge, please see <https://github.com/marketplace/actions/ossf-scorecard-action#scorecard-badge>.
 
 This check passes if:
 
@@ -512,23 +512,23 @@ This check passes if:
 
 This check determines whether the project has generated executable (binary) artifacts in the source repository.
 
-*This is an OpenSSF Scorecard check. For more details please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#binary-artifacts) in the ossf/scorecard repository.*
+*This is an OpenSSF Scorecard check. For more details, please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#binary-artifacts) in the ossf/scorecard repository.*
 
 ### Code review (from OpenSSF Scorecard)
 
 **ID**: `code_review`
 
 This check determines whether the project requires code review before pull requests (merge requests) are merged.
 
-*This is an OpenSSF Scorecard check. For more details please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#code-review) in the ossf/scorecard repository.*
+*This is an OpenSSF Scorecard check. For more details, please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#code-review) in the ossf/scorecard repository.*
 
 ### Dangerous workflow (from OpenSSF Scorecard)
 
 **ID**: `dangerous_workflow`
 
 This check determines whether the project's GitHub Action workflows has dangerous code patterns.
 
-*This is an OpenSSF Scorecard check. For more details please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dangerous-workflow) in the ossf/scorecard repository.*
+*This is an OpenSSF Scorecard check. For more details, please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dangerous-workflow) in the ossf/scorecard repository.*
 
 ### Dependencies policy
 
@@ -546,15 +546,15 @@ This check passes if:
 
 This check tries to determine if the project uses a dependency update tool, specifically [dependabot](https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates) or [renovatebot](https://docs.renovatebot.com/configuration-options/).
 
-*This is an OpenSSF Scorecard check. For more details please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool) in the ossf/scorecard repository.*
+*This is an OpenSSF Scorecard check. For more details, please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool) in the ossf/scorecard repository.*
 
 ### Maintained (from OpenSSF Scorecard)
 
 **ID**: `maintained`
 
 This check determines whether the project is actively maintained.
 
-*This is an OpenSSF Scorecard check. For more details please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#maintained) in the ossf/scorecard repository.*
+*This is an OpenSSF Scorecard check. For more details, please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#maintained) in the ossf/scorecard repository.*
 
 ### Security insights
 
@@ -600,7 +600,7 @@ CASE SENSITIVE: false
 
 This check tries to determine if the project cryptographically signs release artifacts.
 
-*This is an OpenSSF Scorecard check. For more details please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#signed-releases) in the ossf/scorecard repository.*
+*This is an OpenSSF Scorecard check. For more details, please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#signed-releases) in the ossf/scorecard repository.*
 
 ### Software bill of materials (SBOM)
 
@@ -631,7 +631,7 @@ This check passes if:
 
 This check determines whether the project's automated workflows tokens are set to read-only by default.
 
-*This is an OpenSSF Scorecard check. For more details please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) in the ossf/scorecard repository.*
+*This is an OpenSSF Scorecard check. For more details, please see the [check documentation](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) in the ossf/scorecard repository.*
 
 ## Legal
 

docs/dev.md

@@ -19,7 +19,7 @@ clomonitor_db_init
 clomonitor_db_server
 ```
 
-Once the database server is up an running, we can create the `clomonitor` database and we'll be ready to go:
+Once the database server is up and running, we can create the `clomonitor` database and we'll be ready to go:
 
 ```sh
 clomonitor_db_create
@@ -47,7 +47,7 @@ clomonitor_db_migrate
 
 ### Database tests
 
-If you plan to do some work on the database layer, some extra setup is needed to be able to run the database tests. [Schema and database functions are tested](https://github.com/cncf/clomonitor/tree/main/database/tests) using the unit testing framework [pgTap](https://pgtap.org), so you need to [install](https://pgtap.org/documentation.html#installation) the pgTap PostgreSQL extension on your machine. To run the tests you will also need to install a perl tool called [pg_prove](https://pgtap.org/pg_prove.html) from CPAN (`cpan TAP::Parser::SourceHandler::pgTAP`).
+If you plan to do some work on the database layer, some extra setup is needed to be able to run the database tests. [Schema and database functions are tested](https://github.com/cncf/clomonitor/tree/main/database/tests) using the unit testing framework [pgTap](https://pgtap.org), so you need to [install](https://pgtap.org/documentation.html#installation) the pgTap PostgreSQL extension on your machine. To run the tests, you will also need to install a perl tool called [pg_prove](https://pgtap.org/pg_prove.html) from CPAN (`cpan TAP::Parser::SourceHandler::pgTAP`).
 
 Similarly to what we did during our initial database setup, we'll create a configuration file for Tern for the tests database in the same folder (`~/.config/clomonitor`), called `tern-tests.conf` with the following content (please adjust if needed):
 
@@ -81,7 +81,7 @@ insert into foundation values ('cncf', 'CNCF', 'https://raw.githubusercontent.co
 
 The `registrar` component will process the foundations' data files and register the projects available.
 
-At this point our database is ready to launch our local instance of CLOMonitor and start doing some work on it.
+At this point, our database is ready to launch our local instance of CLOMonitor and start doing some work on it.
 
 ## Backend
 
@@ -122,7 +122,7 @@ Now you can run the `apiserver`:
 clomonitor_apiserver
 ```
 
-The `apiserver` process launches an http server that serves the web application and the API that powers it. Once it is up and running, you can point your browser to [http://localhost:8000](http://localhost:8000) and you should see the CLOMonitor web application. Initially there won't be any projects listed on it, but we'll take care of that in the next section.
+The `apiserver` process launches an http server that serves the web application and the API that powers it. Once it is up and running, you can point your browser to [http://localhost:8000](http://localhost:8000) and you should see the CLOMonitor web application. Initially, there won't be any projects listed on it, but we'll take care of that in the next section.
 
 ### Registrar
 
@@ -181,7 +181,7 @@ Depending on the speed of your Internet connection and machine, this may take on
 
 ### Linter CLI
 
-In the section above we saw how the `tracker` is able to lint all repositories registered in the database. But sometimes it may be desirable to lint a single repository manually in an isolated way, maybe to quickly test some checks or to integrate with some other processes, like continuous integration or deployment tools. The `linter CLI` tool is designed to help in those scenarios.
+In the section above, we saw how the `tracker` is able to lint all repositories registered in the database. But sometimes, it may be desirable to lint a single repository manually in an isolated way, maybe to quickly test some checks or to integrate with some other processes, like continuous integration or deployment tools. The `linter CLI` tool is designed to help in those scenarios.
 
 CLOMonitor delegates some of the security checks to [OpenSSF Scorecard](https://github.com/ossf/scorecard), so you'll need to [install it](https://github.com/ossf/scorecard#installation) before running `clomonitor-linter` locally. Both CLOMonitor and [OpenSSF Scorecard](https://github.com/ossf/scorecard) use the Github GraphQL API for some checks, which requires authentication. A Github token (with `public_repo` scope) **must** be provided via the `GITHUB_TOKEN` environment variable to authenticate those requests.
 
@@ -205,7 +205,7 @@ cargo test
 
 The CLOMonitor frontend is a single page application written in [TypeScript](https://www.typescriptlang.org) using [React](https://reactjs.org).
 
-In the backend section we mentioned how to install the frontend dependencies and build it. That should be enough if you are only going to work on the backend. However, if you are planning to do some work on the frontend, it's better to launch an additional server which will rebuild the web application as needed whenever a file is modified.
+In the backend section, we mentioned how to install the frontend dependencies and build it. That should be enough if you are only going to work on the backend. However, if you are planning to do some work on the frontend, it's better to launch an additional server which will rebuild the web application as needed whenever a file is modified.
 
 The frontend development server can be launched using the following command:
 

docs/new-check.md

@@ -19,7 +19,7 @@ The **entrypoint** for the check must be a function named `check`, with the foll
 * Sync check: `pub(crate) fn check(input: &CheckInput) -> Result<CheckOutput<T>>`
 * Async check: `pub(crate) async fn check(input: &CheckInput<'_>) -> Result<CheckOutput<T>>`
 
-In the [clomonitor-core/src/linter/checks/util](https://github.com/cncf/clomonitor/tree/main/clomonitor-core/src/linter/checks/util) directory there are some helpers that can be useful when writing new checks.
+In the [clomonitor-core/src/linter/checks/util](https://github.com/cncf/clomonitor/tree/main/clomonitor-core/src/linter/checks/util) directory, there are some helpers that can be useful when writing new checks.
 
 ### 2. Register the new check