en_help.md

---
layout: page
title: Help
permalink: /help/
ref: help
lang: en
---

Here you find some first aid on the use of JLU GitLab, but it cannot replace the [official user help](https://gitlab.test.uni-giessen.de/help/user/index.md){:target="_blank"}.
For specific information about JLU GitLab, see [information]({{ '/information/#what_is_jlugitlab' | relative_url }}).

## How to use GitLab? {#how_to_gitlab}

TODO: Browser sufficient for many smaller things, for serious work you should install Git locally.

## First steps {#first_steps}

TODO: Rough overview, links to good resources for learning more ([see further help below](#more_help)).

## Visibility of projects {#visibility_projects}

Every project has a visibility setting as either *private*, *internal*, or *public*.
The visibility can only be changed by the *Owner* of the project (see [user roles below](#user_roles)).

- Projects with *private* visibility are only visible to the [members of the project](#user_roles).
- Projects with *internal* visibility are visible to anyone with a user account who is logged in.
  [Please read here what this means in the case of JLU GitLab]({{ '/information/#potential_users' | relative_url }}).
- Projects with *public* visibility are also visible for people without a user account.
  [Please read here what this means in the case of JLU GitLab]({{ '/information/#potential_users' | relative_url }}).

For more details, please refer to the [official documentation](https://gitlab.test.uni-giessen.de/help/public_access/public_access.md#public-access){:target="_blank"}.

## User roles in projects {#user_roles}

TODO: Remaining meanings of *Reporter* through *Owner*.

If you include somebody as a project member, you have to decide what role they should have.
You can pick either *Guest*, *Reporter*, *Developer*, *Maintainer* or *Owner*.
Each role is associated with an increasing set of permissions, see also the [official documentation](https://gitlab.test.uni-giessen.de/help/user/permissions.md#project-members-permissions){:target="_blank"}.
<!-- Also interesting: https://about.gitlab.com/handbook/product/index.html#permissions-in-gitlab -->

### Permissions as *Guest* {#role_guest}

The *Guest* role is for not-active members who can only read content, and open issues and leave comments.

Project members with the *Guest* role can
download the project,
leave comments,
view and pull project files,
view wiki pages,
create new issues,
see related issues,
create confidential issues,
and view self-created confidential issues.

If *Public pipelines* is enabled in *Project Settings > CI/CD*, they can also
see a list of jobs,
see a job log,
and download and browse job artifacts.

### Permissions as *Reporter* {#role_reporter}

The *Reporter* role is for members who get more insights and can work in the issue tracker.

Project members with the *Reporter* role get the following permissions in addition to the *Guest* role:
TODO

<!--
Regarding issues, they can assign and label issues, lock issue threads, and manage the issue tracker and labels.
They can also create code snippets,
see a commit status,
see a container registry,
see environments,
see a list of merge requests,
view project statistics,
and view Error Tracking list.
-->

### Permissions as *Developer* {#role_developer}

TODO 
<!--
create new branches,
and push to or remove non-protected branches.
Regarding merge requests, they can create new ones,
manage/accept,
assign and label them,
and lock merge request threads.
They can create new environments and stop them.
cancel and retry jobs,
create or update commit status,
update a container registry,
remove a container registry image.
Regarding issues, they can create/edit/delete project milestones, and add tags.
apply code change suggestions,
create and edit wiki pages, and
rewrite/remove Git tags.
-->

### Permissions as *Maintainer* {#role_maintainer}

TODO 

### Permissions as *Owner* {#role_owner}

TODO 


## User groups {#groups}

TODO: Group members and their roles and associated permissions.
TODO: Clarification that group projects won't be deleted when leaving JLU, as long as members exist in the group.

[Similar to the visibility of projects](#visibility_projects), the visibility of groups can be set to *private*, *internal*, or *public* to allow access to explicitly selected users, all logged-in users, or any person even without a user account.

## Settings about private information {#private_info}

TODO: Setting of commit email address (in GitLab and locally), hiding of activity and profile, ...

## Last steps {#last_steps}

TODO: Explanation when and what stuff gets deleted once you leave JLU (account data, *own* projects, ...) and what doesn't (group projects including issues and comments, commits, ...).
- Except for commits, stuff will be anonymized (transferred to the Ghost user).

## Further help {#more_help}

TODO: Useful links, maybe in categories.