Structuring your GitLab projects
================================

The following structure of students (and ours) repositories works for us
so feel free to use it as an inspiration.

The whole structure is teacher-centric: the students see their project rather
deeply nested but they can always pin the project to their dashboard and it
does not require any synchronization between teachers of different courses.

The projects are first divided by courses, each course has its own subgroup
under `/teaching/course-unique-code`.

Each semester then has its own group, we often name it by year only.

Our repositories (with slides, for example) are usually grouped under
infrastructure subgroup that is not part of any semestral group as these
repositories usually work across multiple years.

The important part is to have unique naming for student repositories.
We use their login into the Central system to get the unique name, basing
the repository on their real name is possible but can lead to conflicts.

We usually have an extra repository with examples that we also place into
the group for a particular semester.

The student repositories with their submissions can start as empty projects
(the script does not support that directly yet) but we often publish
assignments through changes in a base repository that the students need to
merge into their own projects. Therefore we usually create a common parent
project and *fork* student repositories from that one.

A GitLab limitation when forking a project is that the forked project cannot
be in the same group (namespace) as the target. So it is not possible to fork
from `/teaching/nswi177/base` to `/teaching/nswi177/student-john-doe`.

So in the end the structure for each of our courses looks like this.

``/teaching/COURSE``
   Top level group for each course.

   We keep this group usually public.

``/teaching/COURSE/20XX``
   Group for a particular semester.

   We usually have this group public too.

``/teaching/COURSE/20XX/student-LOGIN``
   Main project for each student.

   If there are multiple projects for each student, we usually prefix them
   with task name, such as `t1-LOGIN` or `t2-LOGIN`.

   These projects are private and hence not visible to anybody who is not
   explicitly assigned to them.

``/teaching/COURSE/20XX/common``
   A namespace with shared repositories visible for all students.

``/teaching/COURSE/20XX/common/student``
   The base project that we fork for each student.

   We often keep this project public (or visible for any logged in user) as
   the students might need to merge from it. Adding all students to it is also
   possible.

   Note that forking a public project creates a public fork
   (see `project-settings` command to change that).

``/teaching/COURSE/20XX/common/examples``
   Whatever other project we need is placed into the ``common`` namespace.

``/teaching/COURSE/infra/``
   A common namespace for our repositories, visible only to the teachers.

If your teaching assistants prefer to organize the projects differently, the
setup of ``/teaching/COURSE/20XX/TEACHER/student-LOGIN`` is also possible
and easy to do with our scripts.