Die nachstehenden Nutzungsbedingungen regeln die Inanspruchnahme des Service „Software Engineering Services“ (im Folgenden „GitLab“) betrieben durch das IT Center der RWTH Aachen University. Zweck des Dienstes ist die sichere und versionierte Speicherung und Verwaltung von Software-Code, der im Rahmen von Forschung und Lehre entwickelt wird.
GitLab wird auf zwei unterschiedlichen Serverinstanzen angeboten.
Die Instanz „git.rwth-aachen.de“ wird mit einer „GitLab for Education“ Lizenz betrieben und darf nur für die Ausbildung von Studierenden und das Entwickeln von OpenSource Software ohne Gewinnerzielungsabsicht genutzt werden. Die Einhaltung der zugrundeliegenden Lizenzbedingungen von GitLab ist dabei verpflichtend.
Die Instanz „git-ce.rwth-aachen.de“ unterliegt einer „Community Edition“ Lizenz. Sie bietet gegenüber der „GitLab for Education Edition“ weniger Funktionen, die Lizenzbedingungen erlauben aber eine freiere Nutzung.
Die hier aufgeführten Nutzungsbedingungen müssen von Nutzenden vor der Nutzung des Services beim Login in die jeweilige Instanz akzeptiert werden. Nachdem die Nutzungsbedingungen in GitLab einmal bestätigt wurden, ist keine weitere Bestätigung notwendig, sofern die Nutzungsbedingungen sich nicht ändern. Möchte ein Nutzender die Nutzungsbedingungen in GitLab erneut einsehen so kann er/sie diese über die URL https://git.rwth-aachen.de/-/users/terms bzw. https://git-ce.rwth-aachen.de/-/users/terms erneut abrufen. Zusätzlich werden die aktuellen Nutzungsbedingungen in unserem Dokumentationsportal veröffentlicht.
Bei Verstoß gegen diese Nutzungsbedingungen behalten wir uns die Sperrung einzelner Projekte und Accounts vor.
Die zentralen GitLab-Instanzen dienen der Verwaltung von Softwareprojekten im Rahmen von Forschung, Lehre und Verwaltung.
Dabei muss inhaltlich zwischen beiden Instanzen unterschieden werden. Das GitLab (git) der RWTH Aachen in der Ultimate for Education Edition ist lizenzbedingt ausschließlich für die Nutzung im Rahmen der Lehre oder für OpenSource lizenzierte Projekte ohne Gewinnerzielungsabsicht bestimmt. Das GitLab (git-ce) der RWTH Aachen in der Communiy Edition ist zusätzlich auch für Zwecke der Forschung und Verwaltung verfügbar.
Die GitLab-Instanzen werden über ein nächtliches Backup gesichert. Dieses Backup dient allerdings nur einer möglichen Wiederherstellung des Gesamtsystems im Fehlerfall und nicht zur Wiederherstellung einzelner Nutzendendaten (Repositorys). Dieses Backup wird 365 Tage aufbewahrt und enthält einen Datenbank-Dump sowie Konfigurationen, die zur Wiederherstellung der GitLab-Instanzen als Gesamtsystem notwendig sind. Die einzelnen Repository-Daten werden nicht gesichert. Folglich ist es nicht möglich, ein gelöschtes Repository wiederherzustellen. Aus diesem Grund ist der Nutzende selbst dafür verantwortlich, seine Repository-Daten (Nutzdaten) zu sichern. LFS (Large File Storage), Registry, Artefakte und Uploads werden im von der GitLab-Instanzen seperaten Object-Storage (S3) gespeichert. Diese Daten sind georedundant auf mehrere Standorte verteilt und werden nicht durch ein Backup gesichert.
Die Projektinhabenden übernehmen die Administration von Mitgliedern, sowie die Konfiguration innerhalb ihrer GitLab-Projekte. Die Rolle des Projektinhabenden setzt einen geeigneten Single Sign-On-Account (DFN-AAI) voraus. Die Accounts von GitLab Nutzenden sind personengebunden und dürfen nicht weitergegeben werden. Somit übernehmen die jeweiligen Nutzenden die volle Verantwortung für ihren persönlichen Account und müssen die Zugangsinformationen sorgfältig und vertraulich aufbewahren. Darüber hinaus übernehmen die Projektinhabenden die Verantwortung für die Inhalte ihrer Projekte. Insbesondere trägt der Projektinhabende bei der Nutzung von GitLab die Verantwortung dafür, dass die Lizenzbedingungen von GitLab eingehalten werden.
Die Nutzenden sind verpflichtet, eine primäre E-Mail-Adresse im Account zu hinterlegen. Diese E-Mail-Adresse muss erreichbar sein und sollte regelmäßig überprüft werden. An diese E-Mail-Adresse werden wichtige Informationen übermittelt.
Der GitLab User-Lifecycle ist ein Prozess, der es ermöglicht, veraltete User-Accounts, die nicht mehr genutzt werden, aus dem System zu entfernen. Dieser Prozess unterscheidet sich bei den beiden Instanzen git.rwth-aachen.de und git-ce.rwth-aachen.de, da hier unterschiedliche Nutzendengruppen tätig sind.
GIT
Nutzende mit Studierenden- und/oder Mitarbeitendenstatus der RWTH Aachen University oder von Hochschulen aus dem NFDI4Ing Konsortium, können sich über den SSO (Single Sign-On) Login einloggen und erhalten so einen Account auf der Instanz, mit der Berechtigung zum Erstellen von persönlichen GitLab Projekten und Gruppenprojekten. Nutzende die sich mit einem GitHub Account einloggen, erhalten nur die Berechtigung zur Mitarbeit in bestehenden Projekten, zu denen sie eingeladen werden müssen. Da die Nutzenden, die sich ausschließlich über GitHub authentifizieren, keine eigenen Projekte erstellen können wird für diese Nutzenden keine Lizenz benötigt. Sie werden als sogenannte externe Nutzer markiert.
Verliert nun ein GitLab Nutzender seinen Studierenden- oder Mitarbeitendenstatus, hat er keine Berechtigung mehr GitLab weiterhin zu nutzen und eine Lizenz zu verwenden. In diesem Fall wird der Nutzende in GitLab blockiert und kann nicht mehr auf seine Projekte zugreifen.
Während des User-Lifecycles wird zunächst geprüft, ob der Nutzende Gruppenprojekte besitzt, in denen er als einziger Projektinhabender eingetragen ist. Sollte dies der Fall sein, so werden automatisch alle Gruppenmitglieder des jeweiligen Gruppenprojektes darüber informiert, dass ein neuer Gruppeninhabender benannt werden muss. Sollte sich hier innerhalb einer Frist von acht Wochen niemand per E-Mail an servicedesk@itc.rwth-aachen.de melden, so wird ein vom IT Center bereitgestellter Systemnutzer als Inhaber eingetragen, damit das Gruppenprojekt weiterhin nutzbar bleibt. Ist der Nutzende nicht alleiniger Inhaber eines Gruppenprojekts besteht kein Handlungsbedarf für dieses Projekt.
Persönliche Projekte werden, nachdem der Nutzende blockiert wurde, exportiert und diesem Nutzenden über einen Download-Link zur Verfügung gestellt. Gruppenprojekte werden aufgrund des Inhaber-Wechsels nicht automatisiert exportiert. Der Nutzende wird über die anstehende Löschung in 12 Wochen per E-Mail informiert und erhält zeitgleich den Download Link zu seinem Projekt-Export. Nach Ablauf von acht der 12 Wochen erfolgt eine Erinnerung per E-Mail, dass die Löschung kurz bevor steht.
Nach dem Ablauf weitere vier Wochen wird der Nutzende noch ein letztes Mal über die Löschung informiert. Der bereitgestellte Export wird dann für weitere vier Wochen vorgehalten und dann automatisch gelöscht.
GIT-CE
Voraussetzung für die Nutzung von GitLab (git-ce) ist die Zugehörigkeit zu einer am NFDI4Ing Konsortium beteiligten Universitäten und Einrichtungen, wozu auch die RWTH Aachen University zählt. Der Studierenden- oder Mitarbeitendenstatus wird in diesem Fall nicht geprüft. Das bedeutet, dass auch RWTH-Partner den Dienst nutzen können.
Sobald die oben genannte Voraussetzung nicht mehr gegeben ist, werden die betroffenen Nutzenden für die Nutzung von GitLab ausgeschlossen. In dem Fall, dass ein Nutzender zu spät bemerkt, dass er die Nutzungsberechtigung verloren hat und das Projekt nicht mehr rechtzeitig exportieren konnte, kann dieser einen Export des persönlichen Projektes beantragen. Dazu ist es notwendig eine E-Mail an servicedesk@itc.rwth-aachen.de zu senden.
GitHub Benutzer werden in GitLab als externe Benutzer behandelt, d.h. sie können in Projekten mitarbeiten, aber keine eigenen Projekte erstellen. Demnach ist ein Export von Projekten nicht vorgesehen.
Hat sich ein GitLab Nutzender seit 24 Monaten weder eingeloggt, noch Änderungen an einem Projekt vorgenommen (commit, push), so gilt dieser Nutzende als inaktiv.
Der User-Lifecycle Prozess soll in diesem Fall sicherstellen, dass sich keine unnötigen Daten ansammeln, insbesondere keine persönlichen Daten von Nutzenden. Daher werden Nutzende die GitLab 24 Monate nicht genutzt haben, per E-Mail über die anstehende Löschung in 12 Wochen informiert. Nach acht vergangenen Wochen erhält der Nutzende eine Erinnerungsmail. Gibt es auch nach weiteren vier Wochen keine Nutzung von GitLab, so wird der Nutzende gelöscht.
Dazu wird zunächst überprüft, ob der Nutzende alleiniger Inhaber eines Gruppenprojektes ist. Ist dies der Fall werden alle Gruppenmitglieder informiert, dass ein neuer Gruppeninhaber benannt werden muss. Sollte sich hier innerhalb der acht Wochen niemand via E-Mail an servicedesk@itc.rwth-aachen.de melden, so wird ein vom IT Center bereitgestellter Systemnutzer als Inhaber eingetragen, damit das Gruppenprojekt weiterhin nutzbar bleibt. Ist der Nutzende nicht alleiniger Inhaber eines Gruppenprojekts besteht kein Handlungsbedarf.
Bevor der Account des inaktiven Nutzenden gelöscht wird, werden die persönlichen Projekte exportiert, sofern vorhanden. Der Download-Link zum Export, sowie eine letzte Information über die Löschung des Accounts, werden dem Nutzenden abschließend per E-Mail zugesandt.
Der bereitgestellte Export wird dann für weitere vier Wochen vorgehalten und anschließend automatisch gelöscht.
Hat sich ein GitLab Nutzender einmalig angemeldet und damit einen Account erstellt, diesen aber innerhalb von 12 Wochen nicht wieder genutzt, also keine eigenen Projekte erstellt und auch an keinem Projekt mitgearbeitet, so wird dieser Account gelöscht und der Nutzende per E-Mail darüber informiert.
Die Löschung eines Nutzenden-Accounts meint nicht nur das Löschen eines Benutzers, sondern auch das Löschen aller Projekte in seinem Namensraums. Ein Namensraum beinhaltet alle persönlichen Projekte, dabei ist es irrelevant ob jemand anderer in dem Projekt Maintainer ist oder nicht. Es ist ebenso irrelevant ob es öffentliche, private oder interne Projekte sind. Alle Projekte im Namensraum werden gelöscht. Das ist technisch von der Anwednung so vorgesehen.
Beispiel:
User: MeinBeispielUser
Namespace: https://git.rwth-aachen.de/meinbeispieluser
Projekte: MeinBeispielProjekt (https://git.rwth-aachen.de/meinbeispieluser/meinbeispielprojekt)
Im Projekt "MeinBeispielProjekt" gibt es weitere 20 Beteiligte und 3 weitere Maintainer. Der Nutzer "MeinBeispielUser" verliert die Berechtigung GitLab zu nutzen, weil er nicht mehr an der RWTH Aachen studiert. Der Nutzer wurde wie eingangs beschrieben angeschrieben und über die anstehende Löschung informiert. Nach 12 Wochen wird nun der Nutzer "MeinBeispielUser" gelöscht und damit auch sein Projekt "MeinBeispielProjekt". Die 23 anderen Nutzenden können nun auch nicht mehr auf das Projekt "MeinBeispielProjekt" zugreifen, da dieses nach der Löschung nicht mehr existiert.
Daher nochmal der folgende explizite Hinweis:
Jedem Projektinhaber muss bewusst sein, dass mit seinem Ausscheiden auch Projekte, die ggf. für andere Teilnehmende ungemein wichtig sind, mit dem Erlöschen des Namespace gelöscht sind. Daher sollte vor dem Ausscheiden aus der RWTH ein Export des Projektes gemacht werden. Sollte jemand anderes an dem Projekt weiterarbeiten, so ist demjenigen der Export zu übermitteln. Das sind Schritte die zu einer angemessenen Übergabe von Projekten gehören. Es ist davon auszugehen, dass dies jedem Teilnehmenden bewusst ist, denn ein Projekt Restore von einzelnen Projekten ist nicht vorgesehen.
Der Projekt-Lifecycle stellt sicher, dass inaktive GitLab Projekte zeitnah entfernt werden, um notwendige Ressourcen für andere, aktive Projekte bereitstellen zu können. Wurde ein GitLab Projekt 24 Monate lang nicht genutzt, wird automatisch der GitLab Projekt Lifecycle Prozess für dieses Projekt aktiv. Gibt es wichtige Gründe, ein Projekt länger als 24 Monate ungenutzt auf GitLab abzulegen, so sieht der Lifecycle eine Whitelist für solche Projekte vor. Dabei wird das Projekt standardmäßig für ein weiteres Jahr, ab dem Datum der Whitelist-Eintragung, aus dem Lifecycle ausgeschlossen. Nutzende die einen wichtigen Grund vorbringen, können Ihr Projekt mit einem Verlängerungsantrag per E-Mail an servicedesk@itc.rwth-aachen.de auf die Whitelist setzen lassen. Es ist dem Nutzenden zusätzlich jederzeit möglich das Projekt in GitLab zu archivieren, wodurch es ausschließlich für lesende Zugriffe verfügbar ist und vom Lifecycle ausgeschlossen wird. Außerdem wird ein Projekt automatisch aus dem Lifecycle Prozess entfernt, sollte es wieder Aktivität im Projekt geben. Das sind beispielsweise Commits, Issues, Kommentare, Milestones, Wikis oder Mitgliedschaftsänderungen.
Da es sich bei GitLab Projekten sowohl um persönliche als auch um Gruppenprojekte handeln kann, muss beim Projekt Lifecycle zwischen diesen beiden Projektarten unterschieden werden.
Bei einem persönlichen Projekt wird der Projektinhabende zunächst automatisiert per E-Mail informiert, dass sein Projekt seit 24 Monaten nicht genutzt wurde und es wird die automatische Löschung des Projektes angekündigt. Projektinhabender ist derjenige, in dessen Namensraum sich das Projekt befindet.
Der Projektinhabende hat nun 25 Wochen Zeit sich zu melden und einen Eintrag auf die Whitelist zu beantragen, das Projekt zu archivieren oder eine Änderung an dem Projekt durchzuführen (https://help.itc.rwth-aachen.de/service/ubrf9cmzd17m/article/7bf138d794de4299ac46d954f708e6eb/). Nach dieser Änderung gilt das Projekt im nächsten Prüfvorgang wieder als aktiv. Wenn innerhalb von 12 Wochen keine nutzerseitige Aktion erfolgt, wird die erste Erinnerungsmail versendet. Die zweite Erinnerung erfolgt daraufhin nach weiteren 12 Wochen. Hat sich auch nach einer weiteren Woche nichts am Status des Projekts geändert, so wird angenommen, dass das Projekt nicht mehr genutzt und auch nicht mehr benötigt wird. Dies führt dazu, dass das Projekt exportiert und anschließend gelöscht wird. Der Projektinhaber wird per E-Mail über die Löschung des Projektes informiert und erhält einen Download-Link über den die exportierten Daten noch vier Wochen heruntergeladen werden können. Nach Ablauf dieser vier Wochen ist der Download-Link ungültig und der Export wird ebenfalls gelöscht.
Bei einem Gruppenprojekt unterscheidet sich der Prozess dahingehend, dass die Benachrichtigungen per E-Mail an alle Projektinhaber gesendet werden. Dies schließt auch vererbte Gruppenberechtigungen aus übergeordneten Gruppen mit ein.
Die Accounts der Projektbeteiligten sind personengebunden und dürfen nicht weitergegeben werden. Somit übernehmen die Projektbeteiligten die volle Verantwortung für ihren persönlichen Account und die sorgfältige Aufbewahrung der Zugangsinformationen. Projektbeteiligte Personen die keinen Single Sign-On Account haben und sich über einen GitHub-Account einloggen, können erst nach Hinzufügen durch einen Projektinhaber an bestehenden Projekten mitarbeiten, jedoch keine eigenen Projekte erstellen.
Je Projekt wird per Default ein Quota von 2 GB eingeräumt. In begründeten Ausnahmefällen kann diese Quota-Grenze erhöht werden. Hierzu ist eine E-Mail an das IT-Servicedesk zu senden und der Mehrbedarf zu begründen. Sollte das Quota überschritten werden, erfolgt eine automatisierte E-Mail-Benachrichtigung an den Projektinhaber mit der Bitte um Reduzierung des Datenbestandes. Sollte dieser Bitte nicht nachgekommen werden und kein Antrag auf Mehrnutzung gestellt werden, behalten wir uns vor, das Projekt zu sperren.
Die Nutzung von GitLab ist kostenfrei; ein Rechtsanspruch auf Registrierung und Nutzung besteht nicht.
Das IT Center übernimmt die Verantwortung für den Betrieb von GitLab. Dies umfasst die (virtuelle) Hardware der Server, die Betriebssysteme sowie die installierte Software. Das IT Center übernimmt keine Haftung für Schäden, die unter anderem durch die Nutzung von GitLab entstehen.
Die RWTH haftet unbeschränkt bei Vorsatz oder grober Fahrlässigkeit, für die Verletzung von Leben, Leib oder Gesundheit und nach den Vorschriften des Produkthaftungsgesetzes. Bei leicht fahrlässiger Verletzung einer Pflicht, die wesentlich für die Erreichung des Vertragszwecks ist (Kardinalpflicht), ist die Haftung der RWTH der Höhe nach begrenzt auf den Schaden, der nach der Art des fraglichen Geschäfts vorhersehbar und typisch ist. Eine weitergehende Haftung der RWTH besteht nicht. Die vorstehende Haftungsbeschränkung gilt auch für die persönliche Haftung der Mitarbeitenden, Vertretenden und Organe der RWTH.
Die Erhebung, Nutzung und Verwendung personenbezogener Daten erfolgt unter Beachtung der einschlägigen Datenschutzbestimmungen. Insbesondere werden keine personenbezogenen Daten unbefugt an Dritte weitergegeben.
The following Terms of Use govern the use of the service "Software Engineering Services" (hereinafter referred to as "GitLab") operated by the IT Center of RWTH Aachen University. The purpose of the service is the secure and versioned storage and management of software code developed in the context of research and teaching.
GitLab is offered on two different server instances.
The instance "git.rwth-aachen.de" is operated with a "GitLab for Education" license and may only be used for the education of students and the development of open source software without the intention of making a profit. Compliance with the underlying license terms of GitLab (https://about.gitlab.com/terms/#edu-oss) is mandatory.
The instance "git-ce.rwth-aachen.de" is subject to a "Community Edition" license. Compared to the "GitLab for Education Edition", it offers fewer functions, but the license conditions allow a freer use.
The terms of use listed here must be accepted by users before using the service when logging into the respective instance. Once the Terms of Use have been confirmed in GitLab, no further confirmation is required unless the Terms of Use change. If a User wishes to view the Terms of Use in GitLab again, he/she can retrieve them again via the URL https://git.rwth-aachen.de/-/users/terms or https://git-ce.rwth-aachen.de/-/users/terms. In addition, the current terms of use are published in our documentation portal.
In case of violation of these terms of use, we reserve the right to block individual projects and accounts.
The central GitLab instances are used to manage software projects in the context of research, teaching and administration.
In terms of content, a distinction must be made between the two instances. The GitLab (git) of RWTH Aachen University in the Ultimate for Education Edition is intended exclusively for use in the context of teaching or for open source licensed projects without the intention of making a profit. RWTH Aachen University's GitLab (git-ce) in the Communiy Edition is additionally available for research and administrative purposes.
The GitLab instances are backed up via a nightly backup. However, this backup is only used for a possible recovery of the entire system in case of failure and not for the recovery of individual user data (repositories). This backup is kept for 365 days and contains a database dump and configurations necessary to restore the GitLab instances as a whole system. The individual repository data is not backed up. Consequently, it is not possible to restore a deleted repository. For this reason, users are responsible for backing up their own repository data (payload data). LFS (Large File Storage), registry, artifacts and uploads are stored in the object storage (S3) separate from the GitLab instances. This data is geo-redundantly distributed across multiple sites and is not backed up.
The project owners take over the administration of members, as well as the configuration within their GitLab projects. The role of project owner requires a suitable single sign-on account (DFN-AAI). The accounts of GitLab users are personal and may not be passed on. Thus, the respective users assume full responsibility for their personal account and must keep the access information carefully and confidentially. In addition, project owners assume responsibility for the content of their projects. In particular, when using GitLab, the project owner is responsible for ensuring that GitLab's license terms are adhered to.
Users are required to provide a primary email address in the account. This e-mail address must be accessible and should be checked regularly. Important information is transmitted to this e-mail address.
The GitLab user lifecycle is a process that enables the removal of obsolete user accounts that are no longer used from the system. This process differs for the two instances git.rwth-aachen.de and git-ce.rwth-aachen.de, as different user groups are active here.
GIT
Users with student and/or employee status from RWTH Aachen University or from universities in the NFDI4Ing consortium can log in via the SSO (Single Sign-On) login and receive an account on the instance with permission to create personal GitLab projects and group projects. Users who log in with a GitHub account will only receive permission to contribute to existing projects, to which they must be invited. Since users who only authenticate via GitHub cannot create their own projects, no license is required for these users. They are marked as so-called external users.
If a GitLab user loses his student or employee status, he is no longer authorized to continue using GitLab and to use a license. In this case, the user is blocked in GitLab and can no longer access their projects.
During the user lifecycle, the system first checks whether the user has group projects in which he is the only project owner. If this is the case, all group members of the respective group project are automatically informed that a new group owner must be named. If no one responds by e-mail to servicedesk@itc.rwth-aachen.de within a period of eight weeks, a system user provided by the IT Center will be entered as the owner so that the group project can continue to be used. If the user is not the sole owner of a group project, no action is required for this project.
Personal projects are exported after the user has been blocked and made available to this user via a download link. Group projects are not exported automatically due to the change of owner. The user will be informed about the upcoming deletion in 12 weeks by e-mail and will receive the download link to his project export at the same time. After eight of the 12 weeks have expired, a reminder is sent by e-mail that deletion is imminent.
After the expiration of another four weeks, the user will be informed one last time about the deletion. The provided export is then kept for another four weeks and then automatically deleted.
GIT-CE
The prerequisite for using GitLab (git-ce) is membership of a university or institution participating in the NFDI4Ing consortium, which includes RWTH Aachen University. Student or employee status is not checked in this case. This means that RWTH partners can also use the service.
As soon as the above-mentioned requirement is no longer met, the affected users will be excluded from using GitLab. In the case that a user notices too late that he has lost the usage authorization and could not export the project in time, he can request an export of the personal project. To do this, it is necessary to send an email to servicedesk@itc.rwth-aachen.de.
GitHub users are treated as external users in GitLab, i.e. they can contribute to projects but cannot create their own projects. Accordingly, exporting projects is not provided.
If a GitLab user has neither logged in nor made changes to a project (commit, push) for 24 months, this user is considered inactive.
In this case, the user lifecycle process is intended to ensure that no unnecessary data accumulates, in particular no personal data of users. Therefore, users who have not used GitLab for 24 months will be informed by email about the upcoming deletion in 12 weeks. After eight weeks have passed, the user will receive a reminder email. If there is still no use of GitLab after another four weeks, the user will be deleted.
First, it is checked whether the user is the sole owner of a group project. If this is the case, all group members are informed that a new group owner must be named. If no one responds via e-mail to servicedesk@itc.rwth-aachen.de within eight weeks, a system user provided by the IT center will be entered as the owner so that the group project can continue to be used. If the user is not the sole owner of a group project, no action is required.
Before the account of the inactive user is deleted, the personal projects are exported, if available. The download link for the export, as well as final information about the deletion of the account, will be sent to the user by e-mail.
The provided export will then be kept for another four weeks and then automatically deleted.
If a GitLab user has registered once and thus created an account, but has not used it again within 12 weeks, i.e. has not created any own projects and has not collaborated on any project, this account will be deleted and the user will be informed of this by e-mail.
Deleting a user account means not only deleting a user, but also deleting all projects in his namespace. A namespace contains all personal projects, it is irrelevant if someone else is maintainer in the project or not. It is also irrelevant if they are public, private or internal projects. All projects in the namespace will be deleted. This is technically intended by the application.
Example:
User: MeinBeispielUser
Namespace: https://git.rwth-aachen.de/meinbeispieluser
Projects: MeinBeispielProjekt (https://git.rwth-aachen.de/meinbeispieluser/meinbeispielprojekt)
In the project "MeinBeispielProjekt" there are 20 more participants and 3 more maintainers. The user "MeinBeispielUser" loses the authorization to use GitLab because he is no longer a student at RWTH Aachen. The user was contacted as described above and informed about the upcoming deletion. After 12 weeks the user "MeinBeispielUser" will be deleted and with it his project "MeinBeispielProjekt". The 23 other users can access now also no more to the project "MeinBeispielProjekt", since this does not exist after the deletion any longer.
Therefore again the following explicit reference:
Each project owner must be aware that with his departure also projects, which are possibly immensely important for other participants, are deleted with the extinction of the namespace. Therefore, an export of the project should be made before leaving the RWTH. If someone else continues to work on the project, the export should be transferred to them. These are steps that belong to an appropriate handover of projects. It can be assumed that every participant is aware of this, because a project restore of individual projects is not intended.
The project lifecycle ensures that inactive GitLab projects are removed in a timely manner to provide necessary resources for other, active projects. If a GitLab project has not been used for 24 months, the GitLab Project Lifecycle process automatically becomes active for that project. If there are important reasons to keep a project unused on GitLab for longer than 24 months, the lifecycle provides a whitelist for such projects. By default, the project is excluded from the lifecycle for an additional year from the date of whitelisting. Users with an important reason can have their project whitelisted by sending an extension request by email to servicedesk@itc.rwth-aachen.de. It is also possible for the user to archive the project in GitLab at any time, making it available for read-only access. In addition, a project is automatically removed from the lifecycle process if there is activity in the project again. This includes commits, issues, comments, milestones, wikis, or membership changes.
Because GitLab projects can be both personal and group projects, the project lifecycle must distinguish between these two types of projects.
In the case of a personal project, the project owner is first automatically informed by email that his project has not been used for 24 months and the automatic deletion of the project is announced. The project owner is the person in whose namespace the project is located.
The project owner now has 25 weeks to get in touch and request an entry on the whitelist, archive the project or make a change to the project (https://help.itc.rwth-aachen.de/service/ubrf9cmzd17m/article/7bf138d794de4299ac46d954f708e6eb/). After this change, the project is considered active again in the next review process. If no user action is taken within 12 weeks, the first reminder email is sent. The second reminder is then sent after another 12 weeks. If there has been no change in the status of the project after a further week, it is assumed that the project is no longer being used and is also no longer required. This leads to the project being exported and subsequently deleted. The project owner is informed by e-mail about the deletion of the project and receives a download link via which the exported data can be downloaded for another four weeks. After these four weeks, the download link is invalid and the export is also deleted.
For a group project, the process differs in that notifications are sent to all project owners via email. This also includes inherited group permissions from parent groups.
The accounts of the project participants are personal and may not be passed on. Thus, the project participants take full responsibility for their personal account and the careful storage of the access information. Project participants who do not have a single sign-on account and log in via a GitHub account can only contribute to existing projects after being added by a project owner, but cannot create their own projects.
A quota of 2 GB is granted per project by default. In justified exceptional cases, this quota limit can be increased. To do this, an e-mail must be sent to the IT service desk and the additional requirement must be justified. If the quota is exceeded, an automated e-mail notification is sent to the project owner with a request to reduce the amount of data. If this request is not complied with and no request for additional use is made, we reserve the right to block the project.
The use of GitLab is free of charge; there is no legal claim to registration and use.
The IT Center assumes responsibility for the operation of GitLab. This includes the (virtual) hardware of the servers, the operating systems as well as the installed software. The IT Center assumes no liability for damages caused by, among other things, the use of GitLab.
RWTH shall be liable without limitation in the event of intent or gross negligence, for injury to life, limb or health and in accordance with the provisions of the Product Liability Act.
In the event of a slightly negligent breach of an obligation that is essential for achieving the purpose of the contract (cardinal obligation), the liability of RWTH shall be limited to the amount of the damage that is foreseeable and typical for the type of transaction in question.
RWTH shall have no further liability.
The above limitation of liability shall also apply to the personal liability of employees, representatives and bodies of RWTH.
The collection, use and utilization of personal data is carried out in compliance with the relevant data protection regulations. In particular, no personal data will be disclosed to third parties without authorization.