Grammar any typo fixes

000-packages.md

@@ -1,4 +1,4 @@
-# 000 - Packages
+# 000 — Packages
 
 Yii3 team divided the framework into several packages that conform to the following agreements.
 

001-yii-values.md

@@ -1,4 +1,4 @@
-# 001 - Yii goal and values
+# 001 — Yii goal and values
 
 ## Goal
 

002-issue-workflow.md

@@ -1,4 +1,4 @@
-# 002 - Issue workflow
+# 002 — Issue workflow
 
 The process of handing incoming issues is the following:
 
@@ -14,7 +14,7 @@ We've many roles:
 - Contributors - create code for pull requests.
 - Code reviewers - review pull requests.
 
-A single person may take one or more roles in the issue resolving process.
+A single person may take one or more roles in the issue-resolving process.
 
 ## Labels
 

003-roadmap.md

@@ -1,15 +1,15 @@
-# 003 - Roadmap
+# 003 — Roadmap
 
 We want Yii 3 to:
 
-- Not limit a developer in choosing architecture. Allow anything from "classic" MVC to DDD.
-- Be based on best practices such as SOLID, GRASP etc. and teach them to community.
+- Not limit a developer to choosing architecture. Allow anything from "classic" MVC to DDD.
+- Be based on the best practices such as SOLID, GRASP, etc. and teach them to the community.
 - Keep the most good things from Yii 2.
 - Be more open to the global PHP community and infrastructure.
 
 ## PSRs compliance
 
-PSR compliance helps with customizability, ability to use general PHP libraries and implement fewer wrappers.
+PSR compliance helps with customizability, the ability to use general PHP libraries and implement fewer wrappers.
 Here's the list of PSRs we want to implement.
 
 ### PSR-3 Logger
@@ -118,7 +118,7 @@ Implemented as a [separate package that isn't dependent on a framework](https://
 
 - [x] Separate web and console application
 - [x] Possibly eliminate base application (still needed)
-- [x] Create interface for console (using Symfony one)
+- [x] Create an interface for the console (using Symfony one)
 - [x] Implementation may be one of the popular ones (using Symfony one)
 - [x] Ensure application can add commands via config
 

004-namespaces.md

@@ -1,4 +1,4 @@
-# 004 - Namespaces
+# 004 — Namespaces
 
 Package namespace rules are the following:
 
@@ -10,12 +10,12 @@ Package namespace rules are the following:
 
 Some examples:
 
-| Package                    | Namespace
-|----------------------------|-----------------
-| yiisoft/yii-web            | Yiisoft\Yii\Web
-| yiisoft/di                 | Yiisoft\Di
-| yiisoft/db-mysql           | Yiisoft\Db\Mysql
-| yiisoft/friendly-exception | Yiisoft\FriendlyException
+| Package                    | Namespace                 |
+|----------------------------|---------------------------|
+| yiisoft/yii-web            | Yiisoft\Yii\Web           |
+| yiisoft/di                 | Yiisoft\Di                |
+| yiisoft/db-mysql           | Yiisoft\Db\Mysql          |
+| yiisoft/friendly-exception | Yiisoft\FriendlyException |
 
 ## References
 

005-development-tool.md

@@ -1,7 +1,7 @@
-# 005 - Yii development tool
+# 005 — Yii development tool
 
-For Yii 3 the number of packages increased significantly to achieve more reusability and independent releases.
-To ease development of the framework itself we've created a special tool available from [yiisoft/yii-dev-tool](https://github.com/yiisoft/yii-dev-tool).
+For Yii3, the number of packages increased significantly to achieve more reusability and independent releases.
+To ease development of the framework itself, we've created a special tool available from [yiisoft/yii-dev-tool](https://github.com/yiisoft/yii-dev-tool).
 
 ```
 $ ./yii-dev
@@ -36,9 +36,9 @@ There are many commands available. The most important ones are `install` and `up
 1. Install/update all packages listed in [`packages.php`](https://github.com/yiisoft/yii-dev-tool/blob/master/packages.php)
    or individual package from that list if specified.
 2. For every package installed check `vendor` directory for packages listed in `packages.php`.
-   If there is any, replace package directory with a symlink to another package source.
+   If there is any, replace the package directory with a symlink to another package source.
 
-As a result you will have many packages using each other, so there is no need to `git push` and `composer install` / `composer update`
+As a result, you will have many packages using each other, so there is no need to `git push` and `composer install` / `composer update`
 during development.
 
 A [detailed example](https://github.com/yiisoft/yii-dev-tool#usage-example) of using the tool is available in its README.

006-git-commit-messages.md

@@ -1,17 +1,17 @@
-# 006 - Git commit messages
+# 006 — Git commit messages
 
 
 ## Subject line
 
 - Use `#123` to reference issue by number
 - Use imperative mood that's `Fix`, not `Fixed`
-- Don't add period at the end
+- Don't add a period at the end
 - Use `[skip ci]` if there is no need to run unit tests
 - Start with a capital letter
 - Limit to 50 characters
 
 ## Body
 
-Use message body **if** you need an extra explanation. Explain why, not how.
+Use the message body **if** you need an extra explanation. Explain why, not how.
 
 - Limit line length to 72 characters

007-exceptions.md

@@ -1,4 +1,4 @@
-# 007 - Exceptions
+# 007 — Exceptions
 
 - Throw exceptions instead of returning an error code.
 - Exception class name must be suffixed with `Exception`.

008-interfaces.md

@@ -1,4 +1,4 @@
-# 008 - Interfaces
+# 008 — Interfaces
 
 - Interface name should be suffixed with `Interface`.
 

009-design-decisions.md

@@ -1,21 +1,21 @@
-# 009 - Design Decisions
+# 009 — Design Decisions
 
-In this document we list important design decisions taken during Yii 3 development.
+In this document, we list important design decisions taken during Yii3 development.
 
 ## Remove magic properties
 
-Magic properties in Yii 2 were an interesting idea that allowed developer to start with
-public property and then seamlessly migrate to getter/setter called via magic
+Magic properties in Yii 2 were an interesting idea that allowed a developer to start with
+public property and then seamlessly migrate to using getter/setter called via magic
 methods without changing the code.
 
 The main reason for removal in Yii 3 is that it resulted in using public
 properties everywhere, thus lack of encapsulation and code fragility.
 
-## Remove service locator
+## Remove the service locator
 
 Service locator both Yii 1 and Yii 2 was convenient but was also abused a lot.
-Despite dependency injection container was available in Yii 2, service locator
-was generally preferred causing both dependency on the service locator itself,
+Although a dependency injection container was available in Yii 2, service locator
+was generally preferred to cause both a dependency on the service locator itself,
 high coupling, hard to test code.
 
 Yii 3 relies on dependency injection only lowering coupling significantly and
@@ -24,12 +24,12 @@ making code way more testable.
 ## Extract general packages
 
 Yii 1 and Yii 2 were fully closed communities. All the code we had wasn't useful
-outside of Yii, and most of the "external" code wasn't useful in Yii without
+outside Yii, and most of the "external" code wasn't useful in Yii without
 wrappers. It was noted many times by communities external to Yii that many parts
 of Yii are well-designed and unique, and they'd use these if these were available
 as standalone packages.
 
-As part of Yii 3 packages such as cache, RBAC, view etc. were extracted into
+As part of Yii 3 packages such as cache, RBAC, view, etc. were extracted into
 framework-independent packages. Benefits are:
 
 - Increased usage and contribution
@@ -38,24 +38,24 @@ framework-independent packages. Benefits are:
 
 ## Adopt PSRs
 
-The team adopted some PSRs in Yii 2 such as PSR-4 and PSR-2.
-Interfaces in general weren't although Yii is part of PHP-FIG.
+The team adopted some PSRs in Yii 2, such as PSR-4 and PSR-2.
+Interfaces in general weren't, although Yii is part of PHP-FIG.
 Mainly because when Yii 2 was released, these were either in the making or not adopted enough.
 
-Yii 3 benefits from PSRs since there are nowadays many ready to use libraries
-that one can get via Composer: cache backends, middleware, loggers, DI containers
+Yii3 benefits from PSRs since there are nowadays many ready-to-use libraries
+that one can get via Composer: cache backends, middleware, loggers, DI containers,
 etc.
 
-By implementing PSRs in general packages we allow these to be used in more
+By implementing PSRs in general packages, we allow these to be used in more
 projects, thus raising the contribution level.
 
 ## Improve DI container
 
-The problem with Yii 2 container was that it's tailored to be used with Yii 2
+The problem with the Yii 2 container was that it's tailored to be used with Yii 2
 components.
 API isn't well-designed to be used with general PHP classes.
 
-In Yii 3 we ensured that container can be used to conveniently configure any
+In Yii3, we ensured that container can be used to conveniently configure any
 PHP class.
 
 That should result in the absence of Yii-specific wrapper packages and more direct
@@ -75,12 +75,12 @@ Yii 2 has its own version policy. Problems:
 
 - It wasn't standard
 - Composer relies on SemVer
-- It's hard to support a framework built on top of packages if versioning policy
+- It's hard to support a framework built on top of packages if the versioning policy
   isn't strict
 
 ## Prevent validators mutating data
 
-In Yii 1 and Yii 2 validators such as "date" were mutating data.
-It was confusing for a validation process that wasn't initially meant to mutate data it validates.
+In Yii 1 and Yii 2, validators such as "date" were mutating data.
+It was confusing for a validation process not initially meant to mutate data it validates.
 
 [See related discussion](https://forum.yiiframework.com/t/saving-or-killing-non-validation-in-validators/126086).

010-code-style.md

@@ -1,4 +1,4 @@
-# 010 - Code Style
+# 010 — Code style
 
 Code formatting used in Yii 3 packages is based on [PSR-1](https://www.php-fig.org/psr/psr-1/) and
 [PSR-12](https://www.php-fig.org/psr/psr-12/) with extra rules added on top of it.
@@ -8,7 +8,7 @@ Code formatting used in Yii 3 packages is based on [PSR-1](https://www.php-fig.o
 - Use English only.
 - Use camelCase notation, including abbreviations (e.g., `enableIdn`).
 - Use the shortest possible, but an explanatory name.
-- Never trim or abbreviate name.
+- Never trim or abbreviate a name.
 - Postfix classes, interfaces, traits and variables, which is a [collection](https://en.wikipedia.org/wiki/Collection_(abstract_data_type)), with `Collection`.
 
 ## Types
@@ -148,7 +148,7 @@ should be two methods instead of one.
 public function login(bool $refreshPage = true): void;
 ```
 
-Is better to be two methods:
+It is better to be two methods:
 
 ```php
 public function login(): void;

011-error-correction.md

@@ -1,4 +1,4 @@
-# 011 - Error correction
+# 011 — Error correction
 
-If it's unambiguous within a class what developer who incorrectly used the class meant, it's OK to correct the error.
-Otherwise, error MUST NOT be corrected.
+If it's unambiguous within a class what the developer who incorrectly used the class meant, it's OK to correct the error.
+Otherwise, the error MUST NOT be corrected.

012-tests.md

@@ -1,15 +1,14 @@
-# 012 - Tests
+# 012 — Tests
 
-For each package we're adding unit-tests that are run via [PHPUnit](https://phpunit.de/).
+For each package, we're adding unit-tests that are run via [PHPUnit](https://phpunit.de/).
 When designing tests, the following guidelines should be taken into account.
 
 - Test class should be marked as `final` by default.
 - `@test` annotation must not be used, prefix methods with `test`.
 - The test method name must reflect the purpose of the test.
-- "should" must not be used in test method name.
+- "should" must not be used in the test method name.
 - If necessary, the test method phpdoc may describe the desired behavior.
-- The test must be structured as AAA - arrange, act, assert that's first we're preparing what's necessary then making calls
-  then asserting everything is correct.
+- The test must follow AAA: first arrange the necessary preconditions, then act, then assert expected results.
 - There must be one test case per test method that's a single AAA.
 - Test must use public API.
   Private properties or methods shouldn't be accessed, assumptions on internals

013-code-review.md

@@ -1,23 +1,23 @@
-# 013 - Code Review
+# 013 — Code review
 
 Code reviews are essential for the success of the project and are as important as contributing code.
 
-Reviews are handled via GitHub pull requests. When the request is ready for review "status: code review" label
+Reviews are handled via GitHub pull requests. When the request is ready for review, the "status: code review" label is 
 added to it.
 
 [A full list of pull requests that need review](https://github.com/search?q=org%3Ayiisoft+label%3A"status%3Acode+review"&state=open&type=Issues)
 is available at GitHub.
 
 ## Guidelines
 
-- Check out pull request branch, open project in IDE, get a big picture.
-- Does pull request make sense overall?
+- Check out the pull request branch, open the project in the IDE, get a big picture.
+- Does the pull request make sense overall?
 - Run tests and/or application using code from the pull request. Are these OK? 
 - Read all lines of code in the pull request.
 - Could it be done simpler?
 - Are there security issues?
 - Are there performance issues?
-- When leaving comments be polite.
+- When leaving comments, be polite.
 - Avoid code-formatting comments.
 
 ## Mandatory parts

014-docs.md

@@ -1,4 +1,4 @@
-# 014 - Documentation
+# 014 — Documentation
 
 Documentation is one of the most important parts of Yii.
 
@@ -30,7 +30,7 @@ Blocks use the Markdown `> Type: `. There are four block types:
 * `Warning`, for bad security things and other problems
 * `Note`, to emphasize key concepts, things to avoid
 * `Info`, general information (an aside); not as strong as a "Note"
-* `Tip`, pro tips, extras, can be useful but may not be needed by everyone all the time
+* `Tip`, pro tips, extras. It can be useful but may not be needed by everyone all the time
 
 The sentence after the colon should begin with a capital letter.
 
@@ -96,8 +96,8 @@ Each package readme should be placed into `README.md` and contain the following:
 - [ ] Screenshot (if applicable).
 - [ ] Requirements.
 - [ ] Installation. Usually `composer require`.
-- [ ] Getting started. One or two common usage examples demonstrated.
+- [ ] Getting started. One or two common usage examples are demonstrated.
 - [ ] Configuration.
-- [ ] Contributing. Should contain a link to guidelines.
+- [ ] Contributing. It should contain a link to guidelines.
 - [ ] Running tests.
 - [ ] License.

015-phpstorm.md

@@ -1,8 +1,8 @@
-# 015 - PhpStorm metadata and attributes
+# 015 — PhpStorm metadata and attributes
 
 ## PhpStorm metadata
 
-[PhpStorm metadata](https://www.jetbrains.com/help/phpstorm/ide-advanced-metadata.html) helps IDE to understand
+[PhpStorm metadata](https://www.jetbrains.com/help/phpstorm/ide-advanced-metadata.html) helps the IDE to understand
 code better in cases when regular types and PHPDoc tags don't help.
 
 We use the following set of coding styles for metadata.

016-security-workflow.md

@@ -1,8 +1,8 @@
-# 016 - Security workflow
+# 016 — Security workflow
 
 Security issues are typically sent via [a security form](https://www.yiiframework.com/security).
 
-If an issue is reported directly to a public page such as repository issue or a forum topic, get the message
+If an issue is reported directly to a public page such as a repository issue or a forum topic, get the message
 and delete the issue. Say thanks to the reporter and point to the security form for next time.  
 
 ## Verify
@@ -11,7 +11,7 @@ Verify that the issue is valid. Request more information if needed.
 
 ## Add security advisory
 
-Create draft GitHub security advisory.
+Create a draft GitHub security advisory.
 
 ### Find out severity
 
@@ -20,7 +20,7 @@ Create draft GitHub security advisory.
 
 ### Give credit to the reporter
 
-Ask reporter if he wants a credit for finding the issue. If so, point to his GitHub account.
+Ask the reporter if he wants a credit for finding the issue. If so, point to his GitHub account.
 
 ## Request a CVE number
 
@@ -30,13 +30,13 @@ When you're ready, request a CVE.
 
 Prepare a pull request fixing the issue. GitHub allows doing it in a private fork.
 
-## Wait till CVE number is allocated 
+## Wait till the CVE number is allocated 
 
 It usually takes several days.
 
 ## Release
 
-- Merge the patch pull request right before tagging next package release.
+- Merge the patch pull request right before tagging the next package release.
 - Publish security advisory.
 - Add CVE to [FriendsOfPHP/security-advisories](https://github.com/FriendsOfPHP/security-advisories).
   See [#488](https://github.com/FriendsOfPHP/security-advisories/pull/488) as example.