Setting up a course

• It's recommended that instructors make a GitLab Group for course-specific repositories and use sub-groups for each term. The faculty who teach the course can be added as owners at the course group level and then can create the sub-groups for the term.
• For example, a group called CSE 130 is created and the sub-group Fall20 is created. This can reduce administrative overhead. TAs and readers from other quarters don't have access to classes for which they're not course staff. All faculty who are owners of the course group will have access to all repositories for all quarters in the class. Course staff must have created an account before they can be added to a group.

Other Strategies for Organizing Courses

• Students can create their projects in their own namespace and give permissions to them.
• If a project site for the whole class is desired, or groups needed for persistent work teams, please name the group, prefixed with pattern course-termyr, eg. physics115-Fall20. This naming approach will help to avoid naming collisions in future quarters.

Group Name Guidelines

Users also have the ability to create groups. Groups are meant to hold related projects and make the delegation of permissions easier. Projects in a group also have the ability to persist even after the originator of the project is no longer active. Group names must be unique across the system as GitLab uses a flat namespace for groups.  Please observe the following guidelines.

Group names:

•  No generic group names i.e. "My Project Group," "Group1," "Super Awesome Research Group."
• For research groups try to keep group names descriptive and succinct, prefixed by an area of research. Keep in mind, these names will also form part of the project/git repo URL.
• For instructional use, similar guidelines apply.   

• GitLab allows you to move projects between groups and personal spaces if you have appropriate rights in both places. As such, a personal project can be moved into a group quite easily or a project moved between groups if the project expands beyond its original context.

Best Practices

Storing Files: 

• Don't Add Large Files to a Git Repository
• Store large files somewhere else like Google Drive and have your code retrieve them.

Avoiding work Erasure: 

• Users can't "erase" git history by deleting branches. Erasing history can inadvertently erase student work. 
• Most TAs and all readers should have read-only ("reporter") access to student repositories. Again, this reduces the possibility of work being erased.

Avoiding Plagiarism: 

• Users shouldn't commit "derived" files such as object files. Use .gitignore to make this easier to enforce.
• Students in a class should *not* be members of the class group. They should only have access to their own repos; only course staff should be in the class group.