solution loading grammar fixes

Rewritten-docs.md

@@ -1603,37 +1603,39 @@ permission checking with quite a small amount of code.
 
 #### Solution loading
 
-When a solution evaluation on backend is finished, results are saved to
+When a solution evaluation on the backend is finished, the results are saved to
-fileserver and API is notified by broker about this state. Then some further
+the fileserver and the API is notified by the broker. Some further steps needs
-steps needs to be done before the results can be presented to users. For
+to be done at that moment before the results can be presented to the users.
-example, these steps are parsing of the results, computation of score or saving
+Some of these steps are parsing of the results, calculation of the final score,
-structured data into database. There are two main possibilities of loading:
+or saving the structured data into the database. There are two main
-
+possibilities when to process the results:
-- immediately
+
-- on demand
+- immediately after the API server is notified by the backend
-
+- when a user requests the results for the first time
-They are almost equal, none of them provides any kind of big advantage. Loading
+
-solutions immediately is better, because fetching results from client for the
+These options are almost equal, none of them provides any kind of a big
-first time can be a bit faster. On the other hand, loading them on demand when
+advantage. Loading solutions immediately is better, because fetching results
-they are requested for the first time can save some resources when the solution
+by the client for the first time can be a bit faster as the results are already
-results are not important and no one is interested in them.
+processed. On the other hand, processing the results on demand can save some of
-
+the resources when the solution results are not important (e.g., the student
-From this choice, we picked up lazy loading when the results are requested.
+finds a bug in his solution before the submission has been evaluated).
-However, concept of asynchronous jobs is then introduced. This type of job is
+
-useful for batch submitting of jobs, for example rerunning jobs which failed on
+We decided for the lazy loading at the time when the results are requested for
-worker hardware issue. These jobs are typically submitted by different user than
+the first time. However, the concept of asynchronous jobs is then introduced.
-author (administrator for example), so original authors should be notified. In
+This type of job is useful for batch submitting of jobs, for example re-running
-this case it is more reasonable to load the results immediately and optionally
+jobs which failed on a worker hardware issue. These jobs are typically submitted
-send them with the notification. Exactly this is also done, special asynchronous
+by different user than the author (an administrator for example), so the original
-jobs are loaded immediately with email notification to the original job author.
+authors should be notified. In this case it is more reasonable to load the results
-
+immediately and optionally send them a notification via an email. This is exactely
-From a short time distance it seems that immediate loading of all jobs could
+what we do.
-simplify loading code and has no major drawbacks. In the next version of ReCodEx
+
-we will rethink this decision.
+It seems with the benefit of hindsight that immediate loading of all jobs could
+simplify the code and it has no major drawbacks. In the next version of ReCodEx
+we will re-evaluate this decision.
 
 #### Backend management
 
-Considering the fact that we have backend as a separate component which has no
+Considering the fact that we have the backend as a separate component which has no
 clue about administrators and uses only logging as some kind of failure
 reporting. It can be handy to provide this functionality to backend from
 frontend which manages users. The simplest solution would be again to have