$newline text
<section>
  <h2 #courses>_{MsgInfoLecturerCourses}

  <dl .deflist>
    <dt .deflist__dt> Course Names
    <dd .deflist__dd>
      <p>
        ^{newU2WFeat} Any course needs a shorthand for identification, e.g. DBS, PXD, DM, ...
      <p>
        The combination of shorthand, department and semester needs to be unique.<br />
        Creating a course with a shorthand that is not unique for the selected department and semester will be rejected (a corresponding error message will be shown).
      <p>
        Recommendations for course shorthands:
        <ul>
          <li> Try to keep the shorthand as short as possible (10 characters max.). 
               In particular, we advice against choosing the full course title as its shorthand.
               A warning will be shown if a shorthand exceeds the recommended length.
          <li> Avoid adding identifiers for the department (e.g. "MATH"), the semester (e.g. "WS19") or the type (e.g. "SEM") of a course in its shorthand.
      <p>
        ^{plannedFeatInline} It is planned to enable courses to have types (e.g. "Bachelor Seminar" or "Practical Course").<br />
        Students will then be able to explicitely search for courses of a specific type.

    <dt .deflist__dt> Clone Courses
    <dd .deflist__dd>
      <p>
        Lecturers are able to clone <em>any</em> course of their department for the current semester.

        When cloning a course, its shorthand and description will be adopted;
        but not exercise sheets, exams or registrations.
      <p>
        The course description can be composed in Html and
        <em>should contain the module description!

    <dt .deflist__dt> Support for Multiple Departments
    <dd .deflist__dd>
      <p>
        ^{newU2WFeat} Uni2work supports managing multiple departments; prefixing course titles with e.g. "[MATH]" are not necessary anymore.
        Instead, there are now department filters for course lists.
      <p>
        The permissions of Uni2work administrators are limited to courses of their respective departments.
        This means that a Uni2work administrator of the Institute of Informatics cannot access grades from courses of the Department of Maths.

    <dt .deflist__dt> Access to Material
    <dd .deflist__dd>
      The access to exercise sheets, slides and other material can be made dependent on the registration for the course.

    <dt .deflist__dt> Publish Material
    <dd .deflist__dd>
      Slides, code bundles etc. can now be distributed to the participants of a course; also password-protected if wanted.

    <dt .deflist__dt> Course Passwords
    <dd .deflist__dd> ^{newU2WFeat} The registration for a course can be password-protected.

    <dt .deflist__dt> Course Lecturers and Assistants
    <dd .deflist__dd>
      <p>
        Course administrators can assign <em>any</em> user as administrator of the course.

        ^{newU2WFeat} Within a course, all course administrators have the same permissions. Most notably, every course administrator is allowed to edit the list of administrators for this course.

      <p>
        ^{newU2WFeat} Uni2work features "lecturer" and "assistant" as roles:
        lecturers are essentially allowed to create new courses.
        The lecturer permission is differentiated according to department.

        Assistants have the same permissions as lecturers, but only for a particular course.

      <p>
        In UniWorX, there was the role "assistant", 
        i.e. every "administrator" also had to be "lecturer"; 
        there was no differentiation between departments.

    <dt .deflist__dt> Course Participants
    <dd .deflist__dd>
      <p>
        Course participants are now displayed alongside information regarding their study programmes.
        Students of multiple programmes need to select a main subject when registering for a course.
        This can speed up the process of reporting exam results.

      <p>
        ^{probFeatInline} Normally, information regarding students' study programmes is up to date;
        however, outdated data is shown in some cases.<br />
        Therefore, no decisions with severe consequences should be made without consulting the student 
        first, if they are solely based on study programme information (e.g. veto in a central allocation
        of practical courses and seminars).

      <p>
        If only a number (key) is shown instead of a study programme or degree, Uni2work did not yet learn a 
        mapping from this key to its corresponding programme.<br />
        Unfortunately, this needs to happen successively because we cannot get an up-to-date and complete 
        mapping of those keys from the Studentenkanzlei (Student Office).<br />
        ^{probFeatInline} It might happen that a more "general" study programme is shown than the actual 
        one a student is enrolled in (e.g. Media Informatics instead of Human-Computer-Interaction). 
        This problem should be fixed in the near future.

    <dt .deflist__dt> From a Student's Point of View
    <dd .deflist__dd>
      <p>
        ^{newU2WFeat} UniWorX had special links to view a page from a student's point of view ("Aus Studentensicht"), which are not necessary anymore in Uni2work. 
        Instead, one can now #
          <a href=@{AuthPredsR}>temporarily withdraw one's own permissions here
        . To view one's own course from a participant's point of view, one deactivates #
        the permission check "_{MsgAuthTagLecturer}" and/or "_{MsgAuthTagCorrector}".

    <dt .deflist__dt> News
    <dd .deflist__dd>
      <p>
        ^{newFeat 2019 10 7} On the course overview page, one can directly publish news concerning 
        the course ("News").
      <p>
        An RSS feed and email notifications for course news are planned in the future.
  
    <dt .deflist__dt> Dates
    <dd .deflist__dd>
      <p>
        ^{newFeat 2019 10 9} On the course overview page, one can publish dates concerning the course 
        (e.g. weekly date of the lecture, one-time post-exam review, ...).
      <p>
        Email notifications on changes of the dates are planned in the future.

<section>
  <h2 #exercises>_{MsgInfoLecturerExercises}

  <dl .deflist>
    <dt .deflist__dt> Correctors
    <dd .deflist__dd>
      ^{newU2WFeat} Correctors and correction method are selected by the course administrator ad-hoc per exercise sheet; 
      there is no entry for correctors in the course configuration.<br />
      To grant tutors that are no correctors permission to view solutions before the submission deadline, 
      they should be registered as sheet correctors with 0 correction proportions. 

      When creating a new sheet, the settings of the previous sheet are suggested automatically.

    <dt .deflist__dt> Distribution
    <dd .deflist__dd>
      Each submission can be assigned to a corrector.

      An automatic assignment (which aims to be as fair as possible) can be triggered either manually or automatically with the end of the submission period.
  
      ^{newU2WFeat} Correctors can be marked as Absent or Excused per exercise sheet. This way, they will not be 
      automatically assigned as correctors of any submissions. 

      The difference between Absent and Excused correctors is that Absent correctors will be assigned more 
      submissions in the upcoming sheets automatically, to make up for the proportion of the sheet they missed. 
      For Excused correctors, no additional submissions will be assigned later on.

    <dt .deflist__dt> Files
    <dd .deflist__dd>
      ^{newU2WFeat} The exercise sheet and its solution can consist of several files of any type. 
      Instead of having to upload a ZIP file in case of multiple files, they can be uploaded one-by-one in Uni2work.

    <dt .deflist__dt> Hints
    <dd .deflist__dd>
      In addition to exercise sheet and solution, hints (e.g. solutions to tutorial exercises) can be released 
      on a specific date before the submission deadline.

    <dt .deflist__dt> Visibility
    <dd .deflist__dd>
      <p>
        Exercise sheets can be hidden from the participants up to a date "Visible from". 
        This can be used to distribute preliminary sheets to tutors and correctors, 
        i.e. when grading and deadlines are not yet fixed.
      <p>
        The participants only get to see the sheet only once it is visible. 
        However, any files regarding the sheet can only be downloaded once the submission period has started, 
        similar to UniWorX.

    <dt .deflist__dt> Timestamps
    <dd .deflist__dd>
      <p>
        Every file of an exercise sheet is annotated with a timestamp which is visible for the participants. 
      <p>
        A visual highlighting of edited/new files and corresponding notifications is planned, 
        but not yet implemented.

    <dt .deflist__dt> External Submissions
    <dd .deflist__dd>
      External submissions (e.g. of analogue form) 
      can be managed using a pseudonym: 
      <ul>
        <li>
          Create sheets with submission method
          <i>External Submission with Pseudonym</i>
        <li>
          On the overview page of a single sheet, 
          participants can generate a pseudonym for their solution.
          Then they can mark their external submission with it.
          <p>
            The participants need to generate a new pseudonym for each exercise sheet to guarantee 
            the anonymity of their submissions. 
            However, no submission will be created in the system when generating a pseudonym, 
            since not every participant that generates a pseudonym actually submits a solution afterwards. 
        <li>
          <p>
            After the external submissions are distributed to the correctors, 
            the correctors need to 
            <a href="@{CorrectionsCreateR}">
              Create a Submission
            , which can then be corrected as usual.
          <p>
            Such submissions will be accounted for in the next distribution of 
            submissions according to the corrector's correction proportions.

    <dt .deflist__dt #correction-files> Correction files
    <dd .deflist__dd>
      <p>
        Assigned correctors and course administrators can download submissions or collections thereof as ZIP archives.
      <p>
        When doing so correction files are added to each submission.

      <p>
        ^{newU2WFeat} Correction files are formatted primarily as 
        <a href="https://yaml.org">YAML
        \ and are thus easy to parse and edit automatically.

      <p>
        In addition to the YAML part each correction file may contain contain an appended correction comment for the respective students.
        Alternatively (for automatic editing) the comment may be added as a YAML field
        <code>comment
        which then contains the comment as a string.

      <p>
        YAML is compatible with
        <a href="https://www.json.org/json-en.html">JSON
        .
        Correction files may thus be replaced with equivalent JSON files for upload (keeping the same field names).

      <p>
        The exact name or file extension of correction files do not matter; Uni2work only checks whether the filename contains a valid submission number.


<section>
  <h2 #tutorials>_{MsgInfoLecturerTutorials}

  <dl .deflist>
    <dt .deflist__dt> Occurrences
    <dd .deflist__dd>
      Tutorials can consist of multiple regular occurrences which repeat on a weekly basis.
      <br />
      Additionally, an arbitrary number of <i>Exceptions</i> can be created.
      <br />
      An exception to an occurrence overrides the regular schedule. To add an exception, one enters an arbitrary date that lies inside the regular occurrence. <em>All</em> regular occurrences that contain the selected date will then be marked as exception.
      <br />
      An exception that an occurrence takes place in turn overrides exceptions that an occurrence does not take place.
      <br />
      This behaviour can be used to shift single occurrences by selecting a regular occurrence as an exception ("does not take place") and another date as a second exception ("does take place").

    <dt .deflist__dt> Tutors
    <dd .deflist__dd>
      <p>
        Tutors are selected ad-hoc per tutorial.
        <br />
        A tutorial can be assigned to an arbitrary number of tutors, and a tutor can be assigned to an arbitrary number of tutorials.

      <p>
        Tutors have access to the names and study programme information of all participants of their tutorials, can send messages to them (similar to course messages) and are able to remove participants from their tutorials.

      <p>
        ^{newFeat 2019 10 14} Optionally, tutors can be given full control over their tutorials (except deleting 
        them), which means that they can edit rooms and dates of the tutorial.

    <dt .deflist__dt> Registration
    <dd .deflist__dd>
      <p>
        Students can register themselves for tutorials via the course page.
        <br />
        The registration proceeds on a <i>first come, first served</i> basis at the moment.
        <br />
        A prior registration for the course is required.
      <p>
        The registration period for a tutorial can be limited in time.
      <p>
        Tutorials can be provided with a <i>Registration Group</i>. 
        A registration group consists of an arbitrary text that is of no further significance. 
        However, participants are restricted on <i>one tutorial registration per registration group</i>.<br />

        Empty registration groups (i.e. no registration groups have been assigned) count as distinct.
      <p>
        To allow registering for an arbitrary number of tutorials, one can leave every registration group empty.
    
    <dt .deflist__dt> ^{newFeat 2019 10 10} Late Registrations
    <dt .deflist__dd>
      Course administrators can assign course participants to tutorials using the list of course participants.


<section>
  <h2 #exams>_{MsgInfoLecturerExams}
  <p>  Large parts of the management of exams have been implemented and are already usable.<br />
  ^{newU2WFeat} In addition to UniWorX, Uni2work supports more general forms of exams (e.g. oral exams, practical exams), for which participants can be grouped and examined in different rooms and on different occurrences per group.

  <dl .deflist>
    <dt .deflist__dt> Create/Edit
    <dd .deflist__dd>
          Exams can be created by course administrators. 
          A number of optional settings can be made immediately or later on, e.g. visibility or registration period.

    <dt .deflist__dt> Occurrences/Rooms
    <dd .deflist__dd>
          ^{newU2WFeat} An exam can be divided into multiple Occurrences/Rooms; each Occurrence/Room can have an own Occurence and Room.
        <p>
          In its most simple form, there can be exams that can take place in multiple rooms.
        <p>
          There can also be exams that take place on different occurrences, e.g. oral exams for seminars or practical courses.<br />
          These occurrences will be visible for the participants in forms of a table.

    <dt .deflist__dt> Registrations
    <dd .deflist__dd>
          Participants can register for visible exams during the given registration period. 
          The list(s) of participants can be edited online or via CSV export/import.

    <dt .deflist__dt> ^{plannedFeat} Exam Allocations
    <dd .deflist__dd>
          Upon request, Uni2work can manage the distribution of participants to exams (rooms/occurrences) 
          using some criteria, such as name or matriculation number.

    <dt .deflist__dt> ^{plannedFeat} Markings
    <dd .deflist__dd>
          <p>
             It is not possible to enter single exam markings (i.e. points per exam part) at the moment.<br />
             This feature will be implemented in the near future.
          <p>
             Entering exam corrections will happen per exam part.
          <p>
             Optionally, course administrators will be able to assign exam correctors, who will then have permission to enter markings during the correction period.<br />
             The permission to enter an exam marking for single exam parts can be granted to single exam correctors.
          
    <dt .deflist__dt> ^{newFeat 2019 9 25} Results
    <dt .deflist__dd>
          <p>
            The calculation of exam results can be done automatically via Uni2work.<br />
            For this, a grading scale needs to be specified. This scale will then be used to calculate 
            the final results of all exam participants based on their achieved amount of points. 
          <p>
            ^{newU2WFeat} At first, the calculated results will be shown as suggestions only. 
            These suggestions then require manual approval by the course administrator before being accepted 
            as exam results, which can afterwards be sent to the relevant exam offices.

          <p>
            ^{newU2WFeat} The calculated suggestions can also be overriden manually, independent of the grading scale.

    <dt .deflist__dt> ^{newFeat 2019 9 26} Exam Bonus
    <dd .deflist__dd>
          It is possible to calculate bonus points for an exam based on the number of exercise points achieved.<br />
          The conditions for this calculation can be adjusted (e.g. only take bonus into account if the participant 
          already passed without the bonus points).<br />
          An upper bound of possible bonus points needs to be specified. The achieved bonus will then be calculated 
          linearly by taking into account the proportion of achieved exercise points and the maximum number of 
          bonus points.

    <dt .deflist__dt> ^{plannedFeat} Door Signs
    <dd .deflist__dd>
          The printing of door signs ("Quiet please!") with matching exam information is a planned feature that is not yet implemented.

    <dt .deflist__dt> ^{newFeat 2019 9 16} Reporting Exam Results
    <dd .deflist__dd>
        <p>
          Final grades can be automatically sent to the relevant exam offices.
        <p>
          After finalizing an exam (by clicking a button on the list of exam participants), all associated 
          exom offices will be notified that the grading process is finished for this exam.
        <p>
          ^{newU2WFeat} Once an exam office has acknowledged the exam result of a participant, a check mark of the 
          page "Exam Results" will be shown.<br />
          In case of this check mark being absent even after a long period of time, a course administrator should 
          look into reporting the exam result for this participant (e.g. by issueing a proof of participation).

        <p>
          ^{newU2WFeat} Course administrators are allowed to edit final results even after reporting the grades 
          to the exam offices. The offices that are affected by these changes will be automatically notified.


<section>
  <h2 #allocations>_{MsgInfoLecturerAllocations}

  <dl .deflist>
    <dt .deflist__dt> Naming Schema
    <dd .deflist__dd>
      Courses can possess an arbitrary title.<br />
      ^{newU2WFeat} Makeshift shorthands such as [SB], [ZP] etc. are not necessary anymore!

    <dt .deflist__dt> Course Settings
    <dd .deflist__dd>
      <p>
        ^{newU2WFeat} Where appropriate, the course settings are being overriden by necessary settings of the 
        corresponding central allocation (meaning that course administrators cannot make any mistakes anymore).
      <p>
        In particular, the selected registration period will be ignored and any direct registration of students 
        will be prohibited (also coming from course administrators!), until the central allocation process is 
        finished and alternate students ("Nachrücker") are treated.

    <dt .deflist__dt> Individual Applications
    <dd .deflist__dd>
      ^{newU2WFeat} Students are able to apply for each course separately. 
      Application documents may consist of both free text and the submission of files (possibly with predefined 
      filenames).
      
    <dt .deflist__dt> Feedback on Applications
    <dd .deflist__dd>
      If so desired, course administrators can send back feedback on student's applications.

    <dt .deflist__dt> Process
    <dt .deflist__dd>
      ^{allocationInfo}


<section>
  <h2>Miscellaneous
  <dl .deflist>

    <dt .deflist__dt> Planned Maintenance
    <dd .deflist__dd>
      Planned maintenance will be conducted <i>without prior notice</i> 
      on 02:00 every night.<br />
      Please refrain from scheduling any critical deadlines at exactly this time or shortly afterwards.