Improvements

Rewritten-docs.md

@@ -2268,35 +2268,35 @@ particular supervisor should not to be supervisor of the group anymore.
 
 ## Instance administrator
 
-Administrator of instance can be only one per instance. In addition to previous
+Instance administrator can be only one person per instance. In addition to
-roles instance admin should be able to modify instance details, manage licences
+previous roles this administrator should be able to modify the instance details,
-and take care of groups which belong to instance.
+manage licences and take care of top level groups which belong to the instance.
 
 ### Instance management
 
-List of all instances in system can be found under "Instances" link in sidebar.
+List of all instances in the system can be found under "Instances" link in the
-On the mentioned page there is a table of instances with their respective
+sidebar. On that page there is a table of instances with their respective
-admins. If you are admin of one of them you can visit its page by clicking on
+admins. If you are one of them, you can visit its page by clicking on the
-the instance name. On instance details page you can find some description of
+instance name. On the instance details page you can find a description of the
-instance, current groups hierarchy and form for creating new group.
+instance, current groups hierarchy and a form for creating a new group.
 
-If you want to change some of the instance settings follow "Edit instance" link
+If you want to change some of the instance settings, follow "Edit instance" link
-on instance details page. This will take you to instance editation page with
+on the instance details page. This will take you to the instance editation page
-corresponding form. In there you can fill following information:
+with corresponding form. In there you can fill following information:
 
 - name of the instance which will be visible to every other user
 - brief description of instance and for whom it is intended
 - checkbox if instance is open or not which means public or private (hidden from
   potentional users)
 
-If you are done with editation, save filled information by clicking on "Update
+If you are done with your editation, save filled information by clicking on
-instance" button.
+"Update instance" button.
 
-If we go back to the instance details page you can find here "Create new group"
+If you go back to the instance details page you can find there a "Create new
-box which is able to add group to instance. This form is the same as the one for
+group" box which is able to add a group to the instance. This form is the same
-creating subgroup in already existing group so we can skip description of form
+as the one for creating subgroup in already existing group so we can skip
-fields. After successful creation of group it should appear in "Groups
+description of the form fields. After successful creation of the group it will
-hierarchy" box at the top of the page.
+appear in "Groups hierarchy" box at the top of the page.
 
 ### Licenses
 
@@ -2305,29 +2305,29 @@ hierarchy" box at the top of the page.
 
 ## Superadministrator
 
-Superadmin is user with the most priviledges and as such superadmin should be
+Superadministrator is a user with the most privileges and as such superadmin
-quite unique role. Ideally there should be only one of this kind, used with
+should be quite a unique role. Ideally, there should be only oneu ser of this
-special caution and adequate security. With this stated it is obvious that
+kind, used with special caution and adequate security. With this stated it is
-superadmin can perform any action the API is capable of.
+obvious that superadmin can perform any action the API is capable of.
 
 ### Users management
 
-There are only few roles to which users can belong in ReCodEx. Basically there
+There are only a few user roles in ReCodEx. Basically there are only three:
-are only three: _student_, _supervisor_, and _superadmin_. Base role is student
+_student_, _supervisor_, and _superadmin_. Base role is student which is
-which is assigned to every registered user. Roles are stored in database
+assigned to every registered user. Roles are stored in database alongside other
-alongside other information about user. One user always has only one role at the
+information about user. One user always has only one role at the time. At first
-time. At first startup of ReCodEx administrator should create his account and
+startup of ReCodEx, the administrator has to change the role for his/her account
-then change role in database by hand. After that manual intervention into
+manually in the database. After that manual intervention into database should
-database should never be needed.
+never be needed.
 
 There is a little catch in groups and instances management. Groups can have
 admins and supervisors. This setting is valid only per one particular group and
 has to be separated from basic role system. This implies that supervisor in one
 group can be student in another and simultaneously have global supervisor role.
-Changing role from student to supervisor and back is done automatically by
+Changing role from student to supervisor and back is done automatically when the
-application and should not be managed by hand in database! Previously stated
+new privileges are granted to the user, so managing roles by hand in database is
-information can be applied to instances as well, but instances can only have
+not needed. Previously stated information can be applied to instances as well,
-admins.
+but instances can only have admins.
 
 Roles description: