| ... | @@ -59,8 +59,6 @@ These labels are then specified by the users who need quality assurance on their |
... | @@ -59,8 +59,6 @@ These labels are then specified by the users who need quality assurance on their |
|
|
|
|
|
|
|
New labels can be added by everyone but the subscription needs to be carried out individually. Therefore it is better to reuse existing labels.
|
|
New labels can be added by everyone but the subscription needs to be carried out individually. Therefore it is better to reuse existing labels.
|
|
|
|
|
|
|
|
# DRAFT: Implementation (open for discussion)
|
|
## Handling of Merge Requests
|
|
|
|
|
|
|
|
> [name=Fabian] I think that this should entirely go to `Contributing.md`.
|
|
Each issue leads to an associated merge request which inherits the chosen labels. Depending on the nature of the chosen labels, either professors or chief-engineers or technicians are responsible to react to the merge request. Redactional changes or new research topics are usually handled by professors of chief-engineers, while maintenance merge requests are handled by technicians. |
|
|
|
|
\ No newline at end of file |
|
|
Every user needs (technical or redactional) needs to adhere to the Contribution-Guidelines. |
|
|
|
\ No newline at end of file |
|
|
