Merge pull request #246 from una-auxme/242-feature-update-previous-gr…

…oups-development-folder 242 feature update previous groups development folder
una-auxme · Mar 31, 2024 · 021baff · 021baff
2 parents 42f0e51 + ebbfd2f
commit 021baff
Show file tree

Hide file tree

Showing 21 changed files with 633 additions and 331 deletions.
diff --git a/doc/02_development/02_linting.md b/doc/02_development/02_linting.md
@@ -1,5 +1,7 @@
 # Linting
 
+(Kept from previous group [paf22])
+
 To ensure unified standards in the project, the following linters are applied during commit.
 
 ## 🐍 Python conventions

diff --git a/doc/02_development/03_commit.md b/doc/02_development/03_commit.md
@@ -1,5 +1,7 @@
 # Git commit message conventions
 
+(Kept from previous group [paf22])
+
 [Conventional Commits](https://www.conventionalcommits.org/) are enforced by [comlipy](https://gitlab.com/slashplus-build/comlipy/) during commit. The commit message should be structured as follows:
 
 ```text

diff --git a/doc/02_development/04_coding_style.md b/doc/02_development/04_coding_style.md
@@ -1,5 +1,7 @@
 # Coding style guidelines
 
+(Kept from previous group [paf22])
+
 **Summary:** This page contains the coding rules we want to follow as a team to improve readability and reviewing of our code.This document is for reference only and should be consolidated in case of uncertainty of following the style guidelines. Based on PEP 8 (<https://pep8.org/>)
 
 ---
@@ -16,58 +18,59 @@ Josef Kircher
 
 VSCode Extensions:
 
-* autoDostring - Python Docstring Generator by Nils Werner
+- autoDostring - Python Docstring Generator by Nils Werner
 
 To get the ReST format like in Pycharm:
 
-* Go to Extension setting and change it under `Auto Doctring:Docstring Format` to `sphinx-notypes`
+- Go to Extension setting and change it under `Auto Doctring:Docstring Format` to `sphinx-notypes`
 
 ---
 <!-- TOC -->
-* [Coding style guidelines](#coding-style-guidelines)
-  * [Author](#author)
-  * [Date](#date)
-  * [Prerequisite](#prerequisite)
-  * [Code lay-out](#code-lay-out)
-    * [Indentation](#indentation)
-    * [Tabs or Spaces?](#tabs-or-spaces)
-    * [Should a line break before or after a binary operator?](#should-a-line-break-before-or-after-a-binary-operator)
-    * [Blank Lines](#blank-lines)
-    * [Source File Encoding](#source-file-encoding)
-    * [Imports](#imports)
-    * [Module level dunder names](#module-level-dunder-names)
-  * [String Quotes](#string-quotes)
-  * [Whitespace in Expressions and Statements](#whitespace-in-expressions-and-statements)
-    * [Pet Peeves](#pet-peeves)
-    * [Other Recommendations](#other-recommendations)
-  * [When to use trailing commas](#when-to-use-trailing-commas)
-  * [Comments](#comments)
-    * [Block Comments](#block-comments)
-    * [Inline Comments](#inline-comments)
-    * [Documentation Strings](#documentation-strings)
-  * [Naming Conventions](#naming-conventions)
-    * [Overriding Principle](#overriding-principle)
-    * [Descriptive Naming Styles](#descriptive-naming-styles)
-    * [Prescriptive: Naming Conventions](#prescriptive-naming-conventions)
-      * [Names to Avoid](#names-to-avoid)
-      * [ASCII Compatibility](#ascii-compatibility)
-      * [Package and Module Names](#package-and-module-names)
-      * [Class Names](#class-names)
-      * [Type variable names](#type-variable-names)
-      * [Exception Names](#exception-names)
-      * [Global Variable Names](#global-variable-names)
-      * [Function Names](#function-names)
-      * [Function and method arguments](#function-and-method-arguments)
-      * [Method Names and Instance Variables](#method-names-and-instance-variables)
-      * [Constants](#constants)
-      * [Designing for inheritance](#designing-for-inheritance)
-    * [Public and internal interfaces](#public-and-internal-interfaces)
-  * [Programming Recommendations](#programming-recommendations)
-    * [Function Annotations](#function-annotations)
-  * [Footnotes](#footnotes)
-  * [Copyright](#copyright)
-    * [Source](#source)
+- [Coding style guidelines](#coding-style-guidelines)
+  - [Author](#author)
+  - [Date](#date)
+  - [Prerequisite](#prerequisite)
+  - [Code lay-out](#code-lay-out)
+    - [Indentation](#indentation)
+    - [Tabs or Spaces?](#tabs-or-spaces)
+    - [Should a line break before or after a binary operator?](#should-a-line-break-before-or-after-a-binary-operator)
+    - [Blank Lines](#blank-lines)
+    - [Source File Encoding](#source-file-encoding)
+    - [Imports](#imports)
+    - [Module level dunder names](#module-level-dunder-names)
+  - [String Quotes](#string-quotes)
+  - [Whitespace in Expressions and Statements](#whitespace-in-expressions-and-statements)
+    - [Pet Peeves](#pet-peeves)
+    - [Other Recommendations](#other-recommendations)
+  - [When to use trailing commas](#when-to-use-trailing-commas)
+  - [Comments](#comments)
+    - [Block Comments](#block-comments)
+    - [Inline Comments](#inline-comments)
+    - [Documentation Strings](#documentation-strings)
+  - [Naming Conventions](#naming-conventions)
+    - [Overriding Principle](#overriding-principle)
+    - [Descriptive Naming Styles](#descriptive-naming-styles)
+    - [Prescriptive: Naming Conventions](#prescriptive-naming-conventions)
+      - [Names to Avoid](#names-to-avoid)
+      - [ASCII Compatibility](#ascii-compatibility)
+      - [Package and Module Names](#package-and-module-names)
+      - [Class Names](#class-names)
+      - [Type variable names](#type-variable-names)
+      - [Exception Names](#exception-names)
+      - [Global Variable Names](#global-variable-names)
+      - [Function Names](#function-names)
+      - [Function and method arguments](#function-and-method-arguments)
+      - [Method Names and Instance Variables](#method-names-and-instance-variables)
+      - [Constants](#constants)
+      - [Designing for inheritance](#designing-for-inheritance)
+    - [Public and internal interfaces](#public-and-internal-interfaces)
+  - [Programming Recommendations](#programming-recommendations)
+    - [Function Annotations](#function-annotations)
+  - [Footnotes](#footnotes)
+  - [Copyright](#copyright)
+    - [Source](#source)
 <!-- TOC -->
+---
 
 ## Code lay-out
 

diff --git a/doc/02_development/05_git_workflow.md b/doc/02_development/05_git_workflow.md
@@ -1,5 +1,7 @@
 # Git Style
 
+(Kept from previous group [paf22])
+
 **Summary:** This page gives an overview over different types of git workflows to choose from.
 
 ---
@@ -16,18 +18,19 @@ Josef Kircher
 
 ---
 <!-- TOC -->
-* [Git Style](#git-style)
-  * [Author](#author)
-  * [Date](#date)
-  * [Prerequisite](#prerequisite)
-  * [Git workflow](#git-workflow)
-    * [Git Feature Branch](#git-feature-branch)
-      * [Branch strategy](#branch-strategy)
-  * [Git style](#git-style)
-    * [Branch naming](#branch-naming)
-    * [Commit messages](#commit-messages)
-    * [Git commands cheat sheet](#git-commands-cheat-sheet)
-  * [Sources](#sources)
+- [Git Style](#git-style)
+  - [Author](#author)
+  - [Date](#date)
+  - [Prerequisite](#prerequisite)
+  - [Git workflow](#git-workflow)
+    - [Git Feature Branch](#git-feature-branch)
+      - [Branch strategy](#branch-strategy)
+  - [Git style](#git-style-1)
+    - [Branch naming](#branch-naming)
+      - [For example](#for-example)
+    - [Commit messages](#commit-messages)
+    - [Git commands cheat sheet](#git-commands-cheat-sheet)
+  - [Sources](#sources)
 <!-- TOC -->
 
 ## Git workflow
@@ -42,8 +45,8 @@ Josef Kircher
 
 Two types of branches:
 
-* Main: contains production ready code
-* Feature: new branches based on main for each feature
+- Main: contains production ready code
+- Feature: new branches based on main for each feature
 
 ## Git style
 
@@ -65,7 +68,7 @@ GitHub does it for you, when you create a new branch from the issue you are work
 
 ---
 
-* proceed to [Commit Messages](./03_commit.md)
+- proceed to [Commit Messages](./03_commit.md)
 
 ### Git commands cheat sheet
 

diff --git a/doc/02_development/06_pycharm_setup.md b/doc/02_development/06_pycharm_setup.md
@@ -1,5 +1,7 @@
 # PyCharm Professional
 
+(Kept from previous group [paf22])
+
 For a seamless development experience, we recommend the use of [PyCharm Professional](https://www.jetbrains.com/pycharm/).
 
 ## Getting an education license

diff --git a/doc/02_development/07_review_guideline.md b/doc/02_development/07_review_guideline.md
@@ -1,5 +1,7 @@
 # Review Guidelines
 
+(Kept from previous group [paf22])
+
 **Summary:** This page gives an overview over the steps that should be taken during a review and how to give a helpful and constructive review
 
 ---
@@ -16,18 +18,18 @@ Josef Kircher
 
 ---
 <!-- TOC -->
-* [Review Guidelines](#review-guidelines)
-  * [Author](#author)
-  * [Date](#date)
-  * [Prerequisite](#prerequisite)
-  * [How to review](#how-to-review)
-  * [How to comment on a pull request](#how-to-comment-on-a-pull-request)
-  * [Incorporating feedback](#incorporating-feedback)
-    * [Responding to comments](#responding-to-comments)
-    * [Applying suggested changes](#applying-suggested-changes)
-    * [Re-requesting a review](#re-requesting-a-review)
-    * [Resolving conversations](#resolving-conversations)
-  * [Sources](#sources)
+- [Review Guidelines](#review-guidelines)
+  - [Author](#author)
+  - [Date](#date)
+  - [Prerequisite](#prerequisite)
+  - [How to review](#how-to-review)
+  - [How to comment on a pull request](#how-to-comment-on-a-pull-request)
+  - [Incorporating feedback](#incorporating-feedback)
+    - [Responding to comments](#responding-to-comments)
+    - [Applying suggested changes](#applying-suggested-changes)
+    - [Re-requesting a review](#re-requesting-a-review)
+    - [Resolving conversations](#resolving-conversations)
+  - [Sources](#sources)
 <!-- TOC -->
 
 ---
@@ -57,28 +59,28 @@ Josef Kircher
 
 ## How to comment on a pull request
 
-* Familiarize yourself with the context of the issue, and reasons why this Pull Request exists.
-* If you disagree strongly, consider giving it a few minutes before responding; think before you react.
-* Ask, don’t tell. (“What do you think about trying…?” rather than “Don’t do…”)
-* Explain your reasons why code should be changed. (Not in line with the style guide? A personal preference?)
-* Offer ways to simplify or improve code.
-* Avoid using derogatory terms, like “stupid”, when referring to the work someone has produced.
-* Be humble. (“I’m not sure, let’s try…”)
-* Avoid hyperbole. (“NEVER do…”)
-* Aim to develop professional skills, group knowledge and product quality, through group critique.
-* Be aware of negative bias with online communication. (If content is neutral, we assume the tone is negative.) Can you use positive language as opposed to neutral?
-* Use emoji to clarify tone. Compare “✨ ✨ Looks good 👍 ✨ ✨” to “Looks good.”
+- Familiarize yourself with the context of the issue, and reasons why this Pull Request exists.
+- If you disagree strongly, consider giving it a few minutes before responding; think before you react.
+- Ask, don’t tell. (“What do you think about trying…?” rather than “Don’t do…”)
+- Explain your reasons why code should be changed. (Not in line with the style guide? A personal preference?)
+- Offer ways to simplify or improve code.
+- Avoid using derogatory terms, like “stupid”, when referring to the work someone has produced.
+- Be humble. (“I’m not sure, let’s try…”)
+- Avoid hyperbole. (“NEVER do…”)
+- Aim to develop professional skills, group knowledge and product quality, through group critique.
+- Be aware of negative bias with online communication. (If content is neutral, we assume the tone is negative.) Can you use positive language as opposed to neutral?
+- Use emoji to clarify tone. Compare “✨ ✨ Looks good 👍 ✨ ✨” to “Looks good.”
 
 ## Incorporating feedback
 
 ### Responding to comments
 
-* Consider leading with an expression of appreciation, especially when feedback has been mixed.
-* Ask for clarification. (“I don’t understand, can you clarify?”)
-* Offer clarification, explain the decisions you made to reach a solution in question.
-* Try to respond to every comment.
-* Link to any follow up commits or Pull Requests. (“Good call! Done in 1682851”)
-* If there is growing confusion or debate, ask yourself if the written word is still the best form of communication. Talk (virtually) face-to-face, then mutually consider posting a follow-up to summarize any offline discussion (useful for others who be following along, now or later).
+- Consider leading with an expression of appreciation, especially when feedback has been mixed.
+- Ask for clarification. (“I don’t understand, can you clarify?”)
+- Offer clarification, explain the decisions you made to reach a solution in question.
+- Try to respond to every comment.
+- Link to any follow up commits or Pull Requests. (“Good call! Done in 1682851”)
+- If there is growing confusion or debate, ask yourself if the written word is still the best form of communication. Talk (virtually) face-to-face, then mutually consider posting a follow-up to summarize any offline discussion (useful for others who be following along, now or later).
 
 ### Applying suggested changes
 

diff --git a/doc/02_development/08_project_management.md b/doc/02_development/08_project_management.md
@@ -1,5 +1,7 @@
 # Project management
 
+(Kept from previous group [paf22])
+
 **Summary:** We use a [Github Project](https://github.com/users/ll7/projects/2) for project management.
 Any bugs or features requests are managed in Github.
 
@@ -18,19 +20,20 @@ Josef Kircher
 
 ---
 <!-- TOC -->
-* [Project management](#project-management)
-  * [Author](#author)
-  * [Date](#date)
-  * [Prerequisite](#prerequisite)
-  * [Create bug or feature requests](#create-bug-or-feature-requests)
-    * [🐞 Bug](#-bug)
-      * [Example for "Bug"](#example-for--bug-)
-    * [💡 Feature](#-feature)
-      * [Example for "Feature"](#example-for--feature-)
-    * [🚗 Bug in CARLA Simulator](#-bug-in-carla-simulator)
-      * [Example for "Bug in CARLA Simulator"](#example-for--bug-in-carla-simulator-)
-  * [Create a Pull Request](#create-a-pull-request)
-  * [Merging a Pull Request](#merging-a-pull-request)
+- [Project management](#project-management)
+  - [Author](#author)
+  - [Date](#date)
+  - [Prerequisite](#prerequisite)
+  - [Create bug or feature requests](#create-bug-or-feature-requests)
+    - [🐞 Bug](#-bug)
+      - [Example for "Bug"](#example-for-bug)
+    - [💡 Feature](#-feature)
+      - [Example for "Feature"](#example-for-feature)
+    - [🚗 Bug in CARLA Simulator](#-bug-in-carla-simulator)
+      - [Example for "Bug in CARLA Simulator"](#example-for-bug-in-carla-simulator)
+  - [Create a Pull Request](#create-a-pull-request)
+  - [Merging a Pull Request](#merging-a-pull-request)
+  - [Deadlines for pull requests and reviews](#deadlines-for-pull-requests-and-reviews)
 <!-- TOC -->
 
 ---

diff --git a/doc/02_development/09_linter_action.md b/doc/02_development/09_linter_action.md
@@ -1,5 +1,7 @@
 # Github actions
 
+(Kept from previous group [paf22])
+
 **Summary:** This page explains the GitHub lint action we use to unsure Code quality.
 
 ---
@@ -14,15 +16,15 @@ Tim Dreier
 
 ## Table of contents
 <!-- TOC -->
-* [Github actions](#github-actions)
-  * [Author](#author)
-  * [Date](#date)
-  * [Table of contents](#table-of-contents)
-  * [General](#general)
-  * [Pull requests](#pull-requests)
-  * [🚨 Common Problems](#-common-problems)
-    * [1. Error in the markdown linter](#1-error-in-the-markdown-linter)
-    * [2. Error in the python linter](#2-error-in-the-python-linter)
+- [Github actions](#github-actions)
+  - [Author](#author)
+  - [Date](#date)
+  - [Table of contents](#table-of-contents)
+  - [General](#general)
+  - [Pull requests](#pull-requests)
+  - [🚨 Common Problems](#-common-problems)
+    - [1. Error in the markdown linter](#1-error-in-the-markdown-linter)
+    - [2. Error in the python linter](#2-error-in-the-python-linter)
 <!-- TOC -->
 
 ## General
@@ -79,4 +81,4 @@ This step even runs if the markdown linter has already failed.
 This way, all errors of different steps are directly visible
 instead of errors only becoming apparent after errors in the previous steps have been fixed.
 
-* <https://aschmelyun.com/blog/using-docker-run-inside-of-github-actions/>
+- <https://aschmelyun.com/blog/using-docker-run-inside-of-github-actions/>
diff --git a/doc/02_development/10_build_action.md b/doc/02_development/10_build_action.md
@@ -1,5 +1,7 @@
 # GitHub actions
 
+(Kept from previous group [paf22])
+
 **Summary:** This page explains the GitHub build action we use to first:
 
 - create an executable image of our work
@@ -24,17 +26,17 @@ Tim Dreier, Korbinian Stein
   - [Date](#date)
   - [Table of contents](#table-of-contents)
   - [General](#general)
-  - [The Dockerfile (`build/docker/build/Dockerfile`)](#the-dockerfile--builddockerbuilddockerfile-)
+  - [The Dockerfile (`build/docker/build/Dockerfile`)](#the-dockerfile-builddockerbuilddockerfile)
   - [The `build-and-push-image` job](#the-build-and-push-image-job)
-    - [1. Checkout repository (`actions/checkout@v3`)](#1-checkout-repository--actionscheckoutv3-)
-    - [2. Set up Docker Buildx (`docker/setup-buildx-action@v2`)](#2-set-up-docker-buildx--dockersetup-buildx-actionv2-)
-    - [3. Log in to the Container registry (`docker/login-action@v2`)](#3-log-in-to-the-container-registry--dockerlogin-actionv2-)
-    - [4. Bump version and push tag (`mathieudutour/github-tag-action`)](#4-bump-version-and-push-tag--mathieudutourgithub-tag-action-)
+    - [1. Checkout repository (`actions/checkout@v3`)](#1-checkout-repository-actionscheckoutv3)
+    - [2. Set up Docker Buildx (`docker/setup-buildx-action@v2`)](#2-set-up-docker-buildx-dockersetup-buildx-actionv2)
+    - [3. Log in to the Container registry (`docker/login-action@v2`)](#3-log-in-to-the-container-registry-dockerlogin-actionv2)
+    - [4. Bump version and push tag (`mathieudutour/github-tag-action`)](#4-bump-version-and-push-tag-mathieudutourgithub-tag-action)
       - [Example](#example)
     - [5. Get commit hash](#5-get-commit-hash)
     - [6. Build and push Docker image](#6-build-and-push-docker-image)
   - [The drive job](#the-drive-job)
-    - [1. Checkout repository (`actions/checkout@v3`)](#1-checkout-repository--actionscheckoutv3--1)
+    - [1. Checkout repository (`actions/checkout@v3`)](#1-checkout-repository-actionscheckoutv3-1)
     - [2. Run agent with docker-compose](#2-run-agent-with-docker-compose)
     - [3. Copy simulation results file out of container](#3-copy-simulation-results-file-out-of-container)
     - [4. Stop docker-compose stack](#4-stop-docker-compose-stack)