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