typos, grammar, wording

Rewritten-docs.md

@@ -178,9 +178,9 @@ Typical use cases for supported user roles are following:
 ### Exercise evaluation chain
 
 The most important part of the system is evaluation of solutions submitted by
-students. Concepts of consecutive steps from source code to final results
-is described in more detail below to give readers solid overview of what have to
-happen during evaluation process.
+students. The process leading from source code to final results (score) is
+described in more detail below to give readers a solid overview of what happens
+during the evaluation process.
 
 First thing students have to do is to submit their solutions through web user
 interface. The system checks assignment invariants (deadlines, count of
@@ -190,9 +190,9 @@ configuration variant is chosen (one exercise can have multiple variants, for
 example C and Java languages). This exercise configuration is then used for
 taking care of evaluation process.
 
-There is a pool of uniform worker engines dedicated to evaluation jobs. Incoming
-jobs are kept in a queue until a free worker picks them. Worker is capable of
-sequential evaluation of jobs, one at a time.
+There is a pool of uniform worker machines dedicated to evaluation jobs.
+Incoming jobs are kept in a queue until a free worker picks them. Workers are
+capable of sequential evaluation of jobs, one at a time.
 
 The worker obtains the solution and its evaluation configuration, parses it and
 starts executing the contained instructions. It is crucial to keep the worker
@@ -212,9 +212,9 @@ Current system is old, but robust. There were no major security incidents
 during its production usage. However, from today's perspective there are
 several drawbacks. The main ones are:
 
-- **web interface** -- The web interface is simple and fully functional. But
-  rapid development in web technologies opens new horizons of how web interface
-  can be made.
+- **web interface** -- The web interface is simple and fully functional.
+  However, recent rapid development in web technologies opens new horizons of
+  how web interfaces can be made.
 - **web API** -- CodEx offers a very limited XML API based on outdated
   technologies that is not sufficient for users who would like to create custom
   interfaces such as a command line tool or mobile application.
@@ -224,8 +224,8 @@ several drawbacks. The main ones are:
   parallelism is a very important area of computing, so there is requirement to
   test multi-threaded applications too.
 - **instances** -- Different ways of CodEx usage scenarios requires separate
-  instances (Programming I and II, Java, C#, etc.). This configuration is not
-  user friendly (students have to register in each instance separately) and
+  installations (Programming I and II, Java, C#, etc.). This configuration is
+  not user friendly (students have to register in each instance separately) and
   burdens administrators with unnecessary work. CodEx architecture does not
   allow sharing hardware between instances, which results in an inefficient use
   of hardware for evaluation.
@@ -234,7 +234,6 @@ several drawbacks. The main ones are:
   which have a more difficult evaluation chain than simple
   compilation/execution/evaluation provided by CodEx.
 
-
 ## Requirements
 
 There are many different formal requirements for the system. Some of them
@@ -352,7 +351,7 @@ annoyed if they did not.
 
 The survey shows that there are a lot of different requirements and wishes for
 the new system. When the system is ready, it is likely that there will be new
-ideas of how to use the system and thus the system must be designed to be easily
+ideas on how to use the system and thus the system must be designed to be easily
 extendable, so that these new ideas can be easily implemented, either by us or
 community members. This also means that widely used programming languages and
 techniques should be used, so that users can quickly understand the code and
@@ -430,7 +429,7 @@ implies that only a subset of all the features will be implemented in the first
 version, and more of them will come in the following releases.
 
 Gathered features are categorized based on priorities for the whole system. The
-highest priority is the functionality presente in current CodEx. It is a base
+highest priority is the functionality present in current CodEx. It is a base
 line for being useful in production environment. The design of the new solution
 shall allow extending the system easily. Ideas from faculty staff have secondary
 priority, but most of them will be implemented as part of the project. The most
@@ -458,17 +457,17 @@ reasonable wishes of university users and our major design choices.
 
 - modern HTML5 web frontend written in JavaScript using a suitable framework
 - REST API communicating with database, evaluation backend and a file server
-- evaluation backend implemented as a distributed system on top of a message
-  queue framework with master-worker architecture
-- multi-platform worker supporting Linux and Windows environment (latter
-  without sandbox, no general purpose suitable tool available yet)
+- evaluation backend implemented as a distributed system on top of a messaging
+  framework with master-worker architecture
+- multi-platform worker supporting Linux and Windows environment (latter without
+  sandbox, no general purpose suitable tool available yet)
 - evaluation procedure configured in a human readable text file, compound of
   small tasks connected into an arbitrary oriented acyclic graph
 
 The reasons supporting these decisions are explained in the rest of analysis
 chapter. Also a lot of smaller design choices are mentioned including possible
-options, what is picked to implement and why. But first, discuss basic concepts
-of the system.
+options, what is picked to implement and why. But first, we discuss basic
+concepts of the system.
 
 ## Basic concepts