docs: fix typos and grammatical errors

release-management.md

@@ -6,7 +6,7 @@ Release managers are responsible for the release management lifecycle, focusing
 
 ## Pre release planning:
 In this stage, release manager and the team lead will elaborate a plan for the coming release. 
-This should take in account:
+This should take into account:
  - the current issues list (a fair amount of time should be taken to go over the github issues).
  - the current critical bugs.
  - the current roadmap.
@@ -27,8 +27,8 @@ We check all the issues and associated effort and identify critical issues.
 e.g:
  - issues that'll need to be split.
  - issues that miss important information.
- - issues that are dependent each others.
- - issued that require different skills or that the team member is less available during this release.
+ - issues that are dependent on each others.
+ - issues that require different skills or that the team member is less available during this release.
 
 ## Configuring releases: 
 Release managers will oversee the various aspects of a project before it is due to be deployed, ensuring everyone is on track and meeting the agreed timeline.
@@ -56,7 +56,7 @@ The release manager is still responsible for ensuring a project is rolled out sm
 ## Detailed Responsibilities:
 
  - Lead the daily standup meeting.
- - 10 minutes or more are reserved at the end of the daily standup meeting where the release manager update the team on the opened PRs (PRs which aim to be delivered in the planned release). 
+ - 10 minutes or more are reserved at the end of the daily standup meeting where the release manager update the team on the open PRs (PRs which aim to be delivered in the planned release). 
  - Regular check for new filed issues, identify those that require to be published (included in the release)
  - In some really specific situations, it could be required to deploy intermediate releases (e.g critical bug fixes).
  - Planning, refinement, retrospective meetings have to be organized by the release manager and any other required meetings.
@@ -80,7 +80,7 @@ The release manager is still responsible for ensuring a project is rolled out sm
 
 ### coding period
 
-- [ ] 10 min after each daily standup where the release manager give an update of the current situation and ETA.
+- [ ] 10 min after each daily standup where the release manager gives an update of the current situation and ETA.
 - [ ] release manager should make sure to be aware of the current state of each issues and PRs during the coding period in order to have a better overview of who is working on what and best provide support to all the team members that are involved in the release.
 
 ### QA preparation

release-process.md

@@ -9,7 +9,7 @@ This document includes the release instructions for:
  - Updating Remix's beta version on remix-beta.ethereum.org
 
 ## Feature Freeze
-Once feature freeze is done, `remix_beta` should be updated latest to the master which will automatically update `remix-beta.ethereum.org` through a CI job.
+Once feature freeze is done, `remix_beta` should be updated to the latest master which will automatically update `remix-beta.ethereum.org` through a CI job.
 
 Use this unified command:
 

team-best-practices.md

@@ -5,8 +5,8 @@ This document aims to address contributors best practices of the following repos
  - Remix Project: https://github.com/ethereum/remix-project
  - Remix Libraries: https://github.com/ethereum/remix-project/tree/master/libs
 
-This document is not in its final version, **a team meeting which aim to address new/old best practices, feedback, workflows, all kind of issues related to how the team work together occurs every 2 weeks.**
-This document link to other specialised best practices (like coding best practices).
+This document is not in its final version, **a team meeting which aims to address new/old best practices, feedback, workflows, all kind of issues related to how the team works together occurs every 2 weeks.**
+This document link to other specialized best practices (like coding best practices).
 
 Related links:
  - Public Website: https://remix-project.org
@@ -38,7 +38,7 @@ Related links:
 
  - A milestone standup - scheduled before the beginning of each milestone, roughly on a monthly basis - which aim to define what will be included in the **next milestone** and who will work on what. This standup also help to set a clear long term vision.
  
- - A retrospective standup - after each releases - which aim to talk about **best practices in general**: what is good, what is bad, how we can improve workflows.
+ - A retrospective standup - after each release - which aims to talk about **best practices in general**: what is good, what is bad, how we can improve workflows.
 
  - A tour standup - Just after a release or whenever it is needed - which aim to demo, **explain in details** features, bug fixes or any part of the codebase.
  
@@ -122,7 +122,7 @@ Before starting coding, we should ensure all devs / contributors are aware of:
  - The end of a milestone triggers a new release.
  - Milestone items and duration should take in account time spent in bugs fixing and support.
  - The team should commit to the milestone duration.
- - If a dev finish early he/she can help other to push remaining tasks.
+ - If a dev finish early he/she can help others to push remaining tasks.
  - If a dev finish early he/she can work on specifying / integrating the next milestone.
  - A milestone duration is fixed at the start of the milestone (but should better not exceed 1 month).
  - Progress and issues regarding a milestone are discussed on regular standups.