Revert some of the edits

Author: asakaev

docs/blog/_posts/2016-02-03-essence-of-scala.md

@@ -142,4 +142,4 @@ project are important.
     This lets us put other constructs of the Scala language to the test,
     either to increase our confidence that they are indeed sound, or
     to show that they are unsound. In my next blog I will
-    present some issues we have discovered through that exercise.
+    present some of the issues we have discovered through that exercise.

docs/blog/_posts/2019-04-15-14th-dotty-milestone-release.md

@@ -122,7 +122,7 @@ For more information, please see the [documentation](https://dotty.epfl.ch/docs/
 
 ## Other changes
 
-Some other changes include:
+Some of the other changes include:
 
 - `infer` method renamed to `the`, the semantics of which is now the same as that of the `the` method of Shapeless. Namely, the implicits are resolved more precisely – see this [gist](https://gist.github.com/milessabin/8833a1dbf7e8245b30f8) for an example in Shapeless, and the Dotty [documentation](https://dotty.epfl.ch/docs/reference/contextual/given-clauses.html#querying-implied-instances) for more details.
 - The syntax of quoting and splicing was changed. Now the quoting is expressed via `'{ ... }` and `'[...]` and splicing – via `${...}` and `$id`. Please see the [documentation](https://dotty.epfl.ch/docs/reference/metaprogramming/macros.html) for more details on these features.

docs/blog/_posts/2019-05-23-15th-dotty-milestone-release.md

@@ -167,7 +167,7 @@ def eval[T](e: Expr[T]): T = e match {
 We've also plugged a few soundness problems (e.g. [#5667](https://github.com/lampepfl/dotty/issues/5667)) caused by inferring too much when matching on abstract, union and intersection types. For more information, see PR [#5736](https://github.com/lampepfl/dotty/pull/5736).
 
 ## Other changes
-Some other notable changes include the following:
+Some of the other notable changes include the following:
 
 - Singletons are now allowed in union types. E.g. the following is allowed: `object foo; type X = Int | foo.type`.
 - A bunch of improvements was made for the type inference system – see, e.g., PRs [#6454](https://github.com/lampepfl/dotty/pull/6454) and [#6467](https://github.com/lampepfl/dotty/pull/6467).

docs/docs/contributing/procedures/release.md

@@ -58,7 +58,7 @@ Above, `<stable_release>` is the stable version being released. For example, if
 
 Copy and paste the output into the release issue.
 
-The ecosystem update section for some projects also mentions a set of criteria upon which the project is to be marked in the checklist. When the Travis build status is specified next to the project's name, it is to be understood that this build must pass after all the other criteria of that project are checked. Note that due to caching, the label image next to the link may not reflect the real status of the build. Therefore, to verify the status, click on the link and make sure that your recent commit passes.
+The ecosystem update section for some projects also mentions a set of criteria upon which the project is to be marked in the checklist. When the Travis build status is specified next to the project's name, it is to be understood that this build must pass after all of the other criteria of that project are checked. Note that due to caching, the label image next to the link may not reflect the real status of the build. Therefore, to verify the status, click on the link and make sure that your recent commit passes.
 
 When no criteria is specified, common sense is to be used.
 

docs/docs/internals/overall-structure.md

@@ -82,7 +82,7 @@ context".
 
 With these two conventions in place, it has turned out that implicit contexts
 work amazingly well as a device for dependency injection and bulk
-parameterization. There is of course always the danger that an unexpected
+parameterization.  There is of course always the danger that an unexpected
 implicit will be passed, but in practice this has not turned out to be much of
 a problem.
 

docs/docs/internals/periods.md

@@ -4,7 +4,7 @@ title: "Dotc's concept of time"
 ---
 
 Conceptually, the `dotc` compiler's job is to maintain views of various
-artifacts associated with source code at all points in time. But what is
+artifacts associated with source code at all points in time.  But what is
 *time* for `dotc`? In fact, it is a combination of compiler runs and compiler
 phases.
 

docs/docs/reference/contextual/motivation.md

@@ -73,7 +73,7 @@ This design thus avoids feature interactions and makes the language more consist
 
 Could we achieve the same goals by tweaking existing implicits? After having tried for a long time, I believe now that this is impossible.
 
- - First, some problems are clearly syntactic and require different syntax to solve them.
+ - First, some of the problems are clearly syntactic and require different syntax to solve them.
  - Second, there is the problem how to migrate. We cannot change the rules in mid-flight. At some stage of language evolution we need to accommodate both the new and the old rules. With a syntax change, this is easy: Introduce the new syntax with new rules, support the old syntax for a while to facilitate cross compilation, deprecate and phase out the old syntax at some later time. Keeping the same syntax does not offer this path, and in fact does not seem to offer any viable path for evolution
  - Third, even if we would somehow succeed with migration, we still have the problem
  how to teach this. We cannot make existing tutorials go away. Almost all existing tutorials start with implicit conversions, which will go away; they use normal imports, which will go away, and they explain calls to methods with implicit parameters by expanding them to plain applications, which will also go away. This means that we'd have

docs/docs/reference/contextual/relationship-implicits.md

@@ -119,7 +119,7 @@ implicit class CircleDecorator(c: Circle) extends AnyVal {
   def circumference: Double = c.radius * math.Pi * 2
 }
 ```
-Abstract extension methods in traits that are implemented in given instances have no direct counterpart in Scala-2. The only way to simulate this is to make implicit classes available through imports. The Simulacrum macro library can automate this process in some cases.
+Abstract extension methods in traits that are implemented in given instances have no direct counterpart in Scala-2. The only way to simulate these is to make implicit classes available through imports. The Simulacrum macro library can automate this process in some cases.
 
 ### Typeclass Derivation
 

docs/docs/resources/talks.md

@@ -38,7 +38,7 @@ This is a recorded meeting between EPFL and Waterloo, where we introduce denotat
 
 - (Typelevel Summit Oslo, May 2016) [Dotty and types: the story so far](https://www.youtube.com/watch?v=YIQjfCKDR5A) by 
 Guillaume Martres [\[slides\]](http://guillaume.martres.me/talks/typelevel-summit-oslo/).
-Guillaume focused on some practical improvements to the type system that Dotty makes, like the new type parameter 
+Guillaume focused on some of the practical improvements to the type system that Dotty makes, like the new type parameter 
 inference algorithm that is able to reason about the type safety of more situations than scalac.
 
 - (flatMap(Oslo) 2016) [AutoSpecialization in Dotty](https://vimeo.com/165928176) by [Dmitry Petrashko](http://twitter.com/darkdimius) [\[slides\]](https://d-d.me/talks/flatmap2016/#/).