Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
research-topics-mat-tuhh research-topics-mat-tuhh
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 10
    • Issues 10
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 4
    • Merge requests 4
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Fabian Nuraddin Alexander Gabel
  • research-topics-mat-tuhhresearch-topics-mat-tuhh
  • Wiki
  • Workflow

Last edited by Fabian Nuraddin Alexander Gabel Sep 13, 2021
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Workflow

The workflow should be driven by Issue and Incidents. Every series of changes starts by creating an issue.

Motivation

In order to fully use the capabilities of GitLab it is necessary to establish a certain set of prescribed workflow steps with following goals:

  • Localized changes (don't change the whole system at once but by parts)
  • Localized notification (based on localized (to issue type or chair) responsibility)
  • Localized assurance (technical and editorial quality assurance)

Localized Change

This does not mean to only change a file, but to have one dedicated issue/merge-request for a concrete problem. Branches will be deleted after merge (Repository setting). There are standard rules about how large commits etc. should be...

Localized Notification and (Quality) Assurance

By the use of labels, the classification of issues allows to only notify the ones that are needed during the handling of the follow-up merge-request:

General Labels

These labels should be subscribed by the persons in charge of authorizing new features:

  • feature

Theses labels are then used to inform the persons in charge about a proposed feature and also to classify the development process as something that is a new addition.

Technical Labels

Technicians should subscribe to the following labels:

  • bug (prioritized)
  • tech-maintenance (Development and standard tasks in order to assure operability that add nono new functionality)
  • typo (for marginal changes to existing pages that have already undergone quality assurance)

These labels are then specified to inform technical maintainers that something about the webpage, repo does not work as expected or to classify development projects that do not add new functionality (e.g. code refactoring).

Editorial Labels

Professors, Chief-Engineers and other people responsible for editorial quality assurance should subscribe to at least one of the following labels:

  • aa-content
  • cm-content
  • dm-content
  • nm-content
  • st-content

These labels are then specified by the users who need quality assurance on their research topic by their supervisor.

DRAFT: Implementation (open for discussion)

Every user needs (technical or redactional) needs to adhere to the Contribution-Guidelines.

Clone repository
  • Continuous Integration and Continuous Deployment
  • Dependencies
  • Editing Markdown
  • Getting Started
  • Integrations
  • Maintenance
  • Postprocessing
  • Preprocessors
  • Program Flow
  • Repository Structure
  • Styleguide
  • Testing
  • Workflow
  • Home