Fix typos and grammar in docs and issue templates

.github/ISSUE_TEMPLATE/bug_report.md

@@ -13,7 +13,7 @@ If possible fill each section
 # Bug report
 
 <!--
-Verify this steps before writing a new issue:
+Verify these steps before writing a new issue:
 
  - Search for existing issues; it's possible someone has already encountered this bug.
 -->

.github/ISSUE_TEMPLATE/feature_request.md

@@ -13,7 +13,7 @@ If possible fill each section
 # Feature request
 
 <!--
-Verify this steps before suggesting a new feature:
+Verify these steps before suggesting a new feature:
 
   - Check if anyone has suggested this feature before
     https://github.com/freeCodeCamp/devdocs/labels/feature

README.md

@@ -148,7 +148,7 @@ thor console:docs   # Start a REPL in the "Docs" module
 thor test:all       # Run all tests
 thor test:docs      # Run "Docs" tests
 thor test:app       # Run "App" tests
-thor test:coverage  # Run coverage report on "App" tests
+thor test:coverage  # Run coverage report for core tests
 
 # Assets
 thor assets:compile # Compile assets (not required in development mode)

docs/adding-docs.md

@@ -19,6 +19,6 @@ Adding a documentation may look like a daunting task but once you get the hang o
 12. Add the documentation's copyright details to `options[:attribution]`. This is the data shown in the table on the [about](https://devdocs.io/about) page, and is ordered alphabetically. Please see an existing scraper for the typesetting.
 13. Ensure `thor updates:check [my_doc]` shows the correct latest version.
 
-If the documentation includes more than a few hundreds pages and is available for download, try to scrape it locally (e.g. using `FileScraper`). It'll make the development process much faster and avoids putting too much load on the source site. (It's not a problem if your scraper is coupled to your local setup, just explain how it works in your pull request.)
+If the documentation includes more than a few hundred pages and is available for download, try to scrape it locally (e.g. using `FileScraper`). It'll make the development process much faster and avoids putting too much load on the source site. (It's not a problem if your scraper is coupled to your local setup, just explain how it works in your pull request.)
 
 Finally, try to document your scraper and filters' behavior as much as possible using comments (e.g. why some URLs are ignored, HTML markup removed, metadata that way, etc.). It'll make updating the documentation much easier.

docs/filter-reference.md

@@ -9,7 +9,7 @@
 
 ## Overview
 
-Filters use the [HTML::Pipeline](https://github.com/jch/html-pipeline) library. They take an HTML string or [Nokogiri](http://nokogiri.org/) node as input, optionally perform modifications and/or extract information from it, and then outputs the result. Together they form a pipeline where each filter hands its output to the next filter's input. Every documentation page passes through this pipeline before being copied on the local filesystem.
+Filters use the [HTML::Pipeline](https://github.com/jch/html-pipeline) library. They take an HTML string or [Nokogiri](http://nokogiri.org/) node as input, optionally perform modifications and/or extract information from it, and then output the result. Together they form a pipeline where each filter hands its output to the next filter's input. Every documentation page passes through this pipeline before being copied on the local filesystem.
 
 Filters are subclasses of the [`Docs::Filter`](https://github.com/freeCodeCamp/devdocs/blob/main/lib/docs/core/filter.rb) class and require a `call` method. A basic implementation looks like this: