Improve grammar

EN/1_culture.md

@@ -26,7 +26,7 @@ MRI is the reference implementation of the Ruby language, so that approved Ruby
 
 Ruby's primary repository uses Git for source control <https://www.ruby-lang.org/en/community/ruby-core/>. Some people have a right to modify this repository. We call them "Ruby committers". Now we have about 100 Ruby committers all over the world (but the number of active members is much smaller. If you become a Ruby committer, you can't throw away the title of "Ruby committer").
 
-Committers can modify any of the source code of MRI. However, each committer has an area of responsibility. If a committer wants to modify another area, he/she is expected to ask and respect the advice of the responsible committers. For example, ko1 is a VM developer, so that if someone want to change the VM drastically, he wants to be consulted before any changes are committed.
+Committers can modify any of the source code of MRI. However, each committer has an area of responsibility. If a committer wants to modify another area, he/she is expected to ask and respect the advice of the responsible committers. For example, ko1 is a VM developer, so that if someone wants to change the VM drastically, he wants to be consulted before any changes are committed.
 
 There is no formal code review system. We may check committed patches and point out issues that we notice. We use `git bisect` (or similar techniques) to investigate problems (e.g. bug reports). If we have a big change, we ask other committers for a review.
 
@@ -63,7 +63,7 @@ Good bug reports should contain the following:
 For details, please check <https://bugs.ruby-lang.org/projects/ruby/wiki/HowToReport> (English)
 or Japanese version <https://bugs.ruby-lang.org/projects/ruby/wiki/HowToReportJ>.
 
-Good feature request should contains the following:
+Good feature request should contain the following:
 
 * Abstract (short summary)
 * Background (What is the issue you want to solve and why. Use-cases)
@@ -90,7 +90,7 @@ We also need to prepare a variety of environments to run our tests. For example,
 Usually we use Intel x86/64 CPU or ARM processors, but there are other processors that we try to test on.
 The list of Ruby's supported platforms can be found at: <https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/SupportedPlatforms>.
 
-Because MRI is used on many enviroments, it is preferable to run tests on as wide a variety of environments as possible.
+Because MRI is used in many enviroments, it is preferable to run tests on as wide a variety of environments as possible.
 It's common practice to use Continuous Integration (CI) to run automated tests. Ruby is no exception.
 
 In addition to using the popular Travis-CI service, we also run the <http://rubyci.org> site to collect test results run on a wider variety of environments. Typically, a CI system uses its own computing resources. However, our resources are limited. So, instead of preparing and managing the computers for the multitude of environments we need, we gather the results from tests run by volunteers in the community who run tests on their own computing resources. The tool [chkbuild](https://github.com/ruby/chkbuild) builds Ruby, runs tests, generates results, and performs a diff on the output so that we can determine which versions of Ruby have particular bugs.
@@ -134,7 +134,7 @@ If you want to hack deeply into MRI, you need to know the C language.
 
 ### Communication channels
 
-* Ruby's redmine: https://bugs.ruby-lang.org/projects/ruby/
+* Ruby's Redmine: https://bugs.ruby-lang.org/projects/ruby/
     * Ticket
     * Wiki
 * Mailing lists
@@ -156,7 +156,7 @@ If you want to hack deeply into MRI, you need to know the C language.
 
 ## Important note
 
-This article introduces several rather pendantic "rules". However, what we interpreter developers value the most is "Hacking".
+This article introduces several rather pedantic "rules". However, what we interpreter developers value the most is "Hacking".
 If you contribute a great patch, we will support your contribution, even if you don't strictly abide by the above rules.
 
 Write code, and have fun!

EN/2_mri_structure.md

@@ -17,7 +17,7 @@ There are the following topics:
 
 The following commands assume an Unix-like environment, such as Linux, macOS, etc. If you're using a Windows environment, you will need to refer to other resources.
 
-NOTE: We provide experimental docker image: `docker pull koichisasada/rhc`. Use `rubydev` account with `su rubydev` and enjoy hacking.
+NOTE: We provide an experimental docker image: `docker pull koichisasada/rhc`. Use `rubydev` account with `su rubydev` and enjoy hacking.
 
 We assume the use of the following directory structure:
 
@@ -65,7 +65,7 @@ NOTE: Running `make` with the `V=1` option (i.e. `make V=1 -j`, etc.) will outpu
 
 ## Exercise: Execute Ruby programs with the Ruby you built
 
-There are several way to run Ruby scripts on the Ruby you built.
+There are several ways to run Ruby scripts on the Ruby you built.
 
 The simplest way is to launch the installed Ruby directly, i.e. invoke `workdir/install/bin/ruby`. This is the same as invoking a pre-built Ruby binary. However, this means you will need to run `make install` every time you make a change to the Ruby source code, which can be rather time-consuming.
 

EN/3_practice.md

@@ -376,7 +376,7 @@ Try solving the following challenges. `grep` will help you to find similar imple
 * Let's play a trick on MRI. For example, change the behaviour of `Integer#+` to perform subtraction instead. This hack will break your ruby build, so make a new git branch and experiment to see what happens.
 * Use your imagination and try to add an interesting new method.
 
-The following topics are discussed in next chapter, but try to explore them yourself before proceeding:
+The following topics are discussed in the next chapter, but try to explore them yourself before proceeding:
 
 * I described that `Integer#add(n)` had a bug.
   * Write a test which fails due to this bug.

EN/5_performance.md

@@ -29,7 +29,7 @@ There are many performance indicators, I'm writing down those that currently com
 
 Some of these indicators depend on each other, in correlation or in inverse correlation.
 
-Examples of correletions:
+Examples of correlations:
 
 * by dropping memory consumption, cache misses also drop, which improves throughput.
 * by reducing the amount of created objects, throughput increases
@@ -39,8 +39,8 @@ Examples of inverse correlations:
 * to improve the real-time rate, a real-time GC is needed → throughput declines
 * having special code paths for often occurring values might increase memory or disc usage
 
-It's important to be aware which of these indicators need to improve, what influence that will have on the other indicators and if that changes are still in acceptable limits.
-Furthermore, as computers are constantly evolving, it might be important to reevaluate ones choices that were appropriate in the past.
+It's important to be aware which of these indicators need to improve, what influence that will have on the other indicators and if those changes are still in acceptable limits.
+Furthermore, as computers are constantly evolving, it might be important to reevaluate one's choices that were appropriate in the past.
 
 For instance, a long time ago, memory was the main restriction, but the amount of memory we can use has constantly grown over time. But this time we might want to use cloud computing, where memory usage equals money, so memory consumption might be relevant yet again.
 

EN/task_ideas.md

@@ -40,7 +40,7 @@ We file all issues on Redmine <https://bugs.ruby-lang.org/issues/> and there are
 
 (1) Bug tickets
 
-We need to fix many bugs but there we dont have enough resources.
+We need to fix many bugs but there we don't have enough resources.
 Please help us.
 
 (1-1) Check if the bug is reproducible or not
@@ -72,8 +72,8 @@ There are several feature-request tickets.
 (2-1) Consider the feature request
 
 Please consider new features and report your thoughts.
-Concrete use-cases based on your experiences will be help us.
-Conversely, thoughts on just your feelings is not usually enough.
+Concrete use-cases based on your experiences will help us.
+Conversely, thoughts on just your feelings are not usually enough.
 Fact is preferable (for example, consistency with other features, other languages and so on).
 
 (2-2) Try to implement a feature request
@@ -92,7 +92,7 @@ For example, ko1's ticket <https://bugs.ruby-lang.org/issues/14609> is very easy
 And do (2-1) to (2-3).
 
 For example, there are many methods in ActiveSupport but not in Ruby builtin/standard libary.
-Porting them is one topic (but you need to pursuade Matz to introduce it).
+Porting them is one topic (but you need to persuade Matz to introduce it).
 
 ## Visualization