fixup! Docs(repo): Introduce deprecations decision

docs/decisions/010-deprecations.md

@@ -6,15 +6,15 @@ Status: proposed
 
 ## Context
 
-Starting the development of our design system from the scratch, we have been using the version 0 for a long time.
-As [SEMVER suggest][semver-zero-version], we want to communicate to our users that the design system is at early stage and any feature is not considered stable.
-However, from the time our users started to use the design system and testing it, they wanted the components they will not change under the hands.
+Starting the development of our design system from scratch, we have been using version 0 for a long time.
+As [SEMVER suggests][semver-zero-version], we want to communicate to our users that the design system is at an early stage and any feature is not considered stable.
+However, from the time our users started to use the design system and test it, they wanted the components they would not change under the hands.
 They want to API to be more stable and predictable.
 
 Starting the first production usage of the design system, we had to stabilize the API and find another way how to customize and further develop our components.
 But without breaking the existing API.
 
-So, we begun with the research how other libraries are solving this problem.
+So, we began with the research on how other libraries are solving this problem.
 In various libraries like ESLint or [Twig][twig-deprecated] we have found the concept of deprecations.
 
 This suits well to our needs, because we can mark the features we want to change or remove in the future and give our users a clear path how to migrate to the new version.
@@ -29,29 +29,29 @@ We will implement the following deprecation strategy:
 2. Warnings must be disabled in production environments
 3. Each deprecation warning must include:
    - What is being deprecated
-   - When it will be removed (usually next major version)
+   - When it will be removed (usually the next major version)
    - What to use instead
-4. Deprecation warnings will be shown in browser console or in terminal
+4. Deprecation warnings will be shown in the browser console or the terminal
 
 ## Consequences
 
 We will mark any feature that will be considered as a breaking change as deprecated.
 We will maintain DEPRECATIONS-v\*.md files for each major version documenting all deprecations.
-We will include deprecation notice in the commit message as well as in the release notes.
+We will include a deprecation notice in the commit message as well as in the release notes.
 We will provide [migration guides][migration-guides] for each deprecation.
 There will be a "Deprecations" section in each package README.md file pointing to the deprecations list.
 When there will be a deprecation notice in the component's README file it will be pointing to the related deprecation notice in deprecations list.
 Developers will have clear visibility of deprecated features during development.
 Production builds won't be impacted by deprecation warnings.
 Migration to new versions will be easier with clear upgrade paths.
 Testing environments may need to handle warning suppression.
-Additional maintenance effort required to keep deprecation documentation up to date.
+Additional maintenance effort is required to keep deprecation documentation up to date.
 
 ### Breaking Changes without Deprecation
 
-When delivering a new Major version, deprecating some features may not be possible or there will be very short time period to adapt.
+When delivering a new Major version, deprecating some features may not be possible or there will be a very short period to adapt.
 In such cases, the breaking changes can be introduced without deprecation as a standard part of the Major version upgrade.
-We consider there is a no less then 1 month period between the release of the deprecation notice and the release of the new Major version.
+We consider there is a no less than 1 month period between the release of the deprecation notice and the release of the new Major version.
 When the gap is longer, we should deprecate the feature first.
 
 [migration-guides]: https://github.com/lmc-eu/spirit-design-system/blob/main/docs/migrations/README.md