Gamify-IT · cdingm · Jun 30, 2022 · Jun 29, 2022 · Jun 29, 2022 · Jun 29, 2022
diff --git a/.vscode/settings.json b/.vscode/settings.json
@@ -0,0 +1,10 @@
+{
+    "spellright.language": [
+        "en"
+    ],
+    "spellright.documentTypes": [
+        "markdown",
+        "latex",
+        "plaintext"
+    ]
+}
diff --git a/adr/coding-style.md b/adr/coding-style.md
diff --git a/adr/databases.md → adr/databases-2022-06-03.md b/adr/databases.md → adr/databases-2022-06-03.md
diff --git a/adr/documentation-language.md → adr/documentation-language-2022-05-12.md b/adr/documentation-language.md → adr/documentation-language-2022-05-12.md
diff --git a/adr/frontend-technology.md b/adr/frontend-technology.md
diff --git a/adr/general-technology-questions.md → ...eneral-technology-questions-2022-06-03.md b/adr/general-technology-questions.md → ...eneral-technology-questions-2022-06-03.md
@@ -8,18 +8,17 @@ Maybe we can define some of the components (and espatially how WE use them) in t
 The ones i remember are:
 
 1. We have a microservice architecture. So why cant the different backend aspects be written in different languages? Why does it have to be only GO?
-  Answer: Everyone can us the language he wants. Atleast 2 other persons should be able to read/ edit the code.
-  
+  Answer: Everyone can use the language he wants. Atleast 2 other persons should be able to read/ edit the code.
+
 2. What is an IFrame, and how do we use them?
   Answer: Little Website inside another website.
-  
+
 3. What is a DOM?
   Answer: A Website (only HTML).
-  
+
 4. Microservice Communication?
-  Answer: probably rest. 
-  
+  Answer: probably REST.
+
 5. Where is the data stored for each microservice?
   Answer: w.i.p. (probably in multiple databases SQL + noSQL)
 
-(i will extend this list if i remember more.)
diff --git a/adr/inter-team-communication.md → adr/inter-team-communication-2022-05-26.md b/adr/inter-team-communication.md → adr/inter-team-communication-2022-05-26.md
@@ -8,12 +8,14 @@ Currently, it can only be guessed what other team members are doing, leading to
 - everyone is responsible to track what they are currently doing in the GitHub organization project
   - Problem: Where are issues opened that don't belong to a repository (i.e. designing the storyline)?
   - Possible solutions:
-    - do not open an issue for such tasks, simply use a draft in the organization project 
+    - do not open an issue for such tasks, simply use a draft in the organization project
     - extra repo only to track such tasks
     - reuse the docs repo for that, label issues that are only in there because they don't fit anywhere else accordingly (i.e. by setting a corresponding milestone or label)
 - everyone tracks what they are currently doing in an external management system (Jira, ...?)
 
 ## Chosen Solution
 
-- use github project https://github.com/orgs/Gamify-IT/projects?type=beta
-- start of next sprint new planning
+- use the [github project](https://github.com/orgs/Gamify-IT/projects/6)
+- participate in the sprint planning at the start of each sprint
+- participate in the _Daily_ meetings
+
diff --git a/adr/issues-repository-2022-06-03.md b/adr/issues-repository-2022-06-03.md
@@ -0,0 +1,4 @@
+# Issues Respository
+
+We should create all our Issues (Tasks) in the [issues repo](https://github.com/Gamify-IT/issues).  
+This makes it easy for us to reference other issues by their issue number.
diff --git a/adr/issues-repository.md b/adr/issues-repository.md
diff --git a/adr/minigame-guide.md → adr/minigame-guide-2022-05-26.md b/adr/minigame-guide.md → adr/minigame-guide-2022-05-26.md
diff --git a/adr/organizational-structure-2022-05-26.md b/adr/organizational-structure-2022-05-26.md
@@ -0,0 +1,18 @@
+# How do we keep the meeting size small?
+
+Currently, too many people attend the meetings. Oftentimes, (almost) every team member participates.
+
+- ~50-75% of attendees do not participate actively in the meeting
+   -> can be more productive
+- it would be better if everyone specializes on a small topic
+  - where they decide how to proceed instead of letting everyone discuss the big picture without getting anything done
+
+## Possible Solutions
+
+- keep the current approach
+- split all group members into teams of two people specializing on one aspect
+- split all group members into teams of three people specializing on one aspect
+
+## Chosen Solution
+
+- split into smaller teams with variable size
diff --git a/adr/organizational-structure.md b/adr/organizational-structure.md
diff --git a/adr/program-language.md → adr/program-language-2022-05-12.md b/adr/program-language.md → adr/program-language-2022-05-12.md
@@ -1,4 +1,4 @@
 # Which language should be chosen for our program?
 
 - english
-- Sandro was asked and confirmed
+- Sandro was asked and he confirmed that
diff --git a/adr/program-name-2022-05-12.md b/adr/program-name-2022-05-12.md
@@ -0,0 +1,12 @@
+# Which name should our project have?
+
+## Proposals
+
+- `Gamify-IT` (Current)
+- `AWebaGa PlafoCoEdu @FirSem` ( _A web based gaming platform for computer science education in the first semesters_, GitHub slogan)
+- `AWebaGa` (Pronouncable version of above)
+
+## Result
+
+We proposed the new names to the clients but were shut down.
+The name stays as `Gamify-IT`.
diff --git a/adr/program-name.md b/adr/program-name.md
diff --git a/adr/sprint-board-workflow-2022-06-17.md b/adr/sprint-board-workflow-2022-06-17.md
@@ -0,0 +1,39 @@
+# States of Issues in the Project Board
+
+In our GitHub Project Board for our Sprints we have multiple columns for different states of an issue.
+
+## Chosen Solution
+
+We have the following Columns:
+
+### Backlog
+
+Whenever we have an idea for a new issue, we can create one there.
+
+### Ready for another Sprint
+
+The issue can be moved from Backlog to here, when the issue is completely formulated. This includes the `Current Behavior`, `Expected Behavior`, and `Done` sections, where you define what the current behavior is, what the behavior should look like when the issue is closed. Checkpoints should also be created which show the steps that are needed to close the Issue. In case we can already estimate the workload of the issue, we should do it.
+
+### Todo
+
+Every Issue in this column should be closed by the end of the current Sprint. The workload of the issues should already be estimated.
+
+### In Progress
+
+The issues in this column have at least one assignee who is currently working on the issue.
+
+### Ready for PR Review
+
+All tasks in the issue were finished and are ready for review. A Pull-Request should be already created and reviewers are assigned.
+
+### Done
+
+All tasks are done and reviewed by other team members and are merged into the main branch.
+
+### Accepted
+
+The issue was accepted by the supervisors. Normally all issues from the last sprint should be in this column after a review with the supervisors.
+
+### Cancelled
+
+We do not want to delete issues if we figure out that we do not need or dont finish an issue. Instead, it should be documented why the issue was canceled inside the issue and it should be moved into this column.
diff --git a/adr/sprint-board-workflow.md b/adr/sprint-board-workflow.md
diff --git a/adr/time-tracking.md → adr/time-tracking-2022-06-02.md b/adr/time-tracking.md → adr/time-tracking-2022-06-02.md
@@ -1,9 +1,10 @@
 # Should everyone track their times? If yes, how?
 
 ## update 02.06.2022
+
 - use [Google Timesheet](https://docs.google.com/spreadsheets/d/1D1sVVBkDdNDeKyYO22f_tL_WVBzRPppIobpzA3uxNkA/edit?usp=sharing)
 
 ## old
+
 - use toggl with information what was done
 - start timetracking with official start after prototype
-
diff --git a/adr/web-styles-2022-05-12.md b/adr/web-styles-2022-05-12.md
@@ -0,0 +1,12 @@
+# What design library should we use to style our web interfaces?
+
+## Proposals
+
+- Material
+- Bootstrap
+- Tailwind
+
+## Result
+
+- Bootstrap
+- a lot of existing knowledge, integration with vue
diff --git a/adr/web-styles.md b/adr/web-styles.md
diff --git a/conf.py b/conf.py
@@ -37,7 +37,7 @@
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
 # This pattern also affects html_static_path and html_extra_path.
-exclude_patterns = ['_build', 'venv', 'internal', 'README.md', 'dev-manuals/README.md', 'adr/README.md', 'template-README.md', 'user-manuals/README.md', '**/template*.md', 'Thumbs.db', '.DS_Store']
+exclude_patterns = ['_build', 'venv', 'internal', 'README.md', 'dev-manuals/README.md', 'adr/README.md', 'adr/adr-template.md', 'template-README.md', 'user-manuals/README.md', '**/template*.md', 'Thumbs.db', '.DS_Store']
 
 
 # -- Options for HTML output -------------------------------------------------

diff --git a/dev-manuals/README.md b/dev-manuals/README.md
@@ -1,4 +1,3 @@
 # Developer manuals
 
 Contains all information a developer needs to know to collaborate on a repo/ in this project.
-
diff --git a/dev-manuals/tests/testing-plans.md → dev-manuals/architecture/testing-plan.md b/dev-manuals/tests/testing-plans.md → dev-manuals/architecture/testing-plan.md
@@ -1,3 +1,5 @@
+# How do we test a specific service?
+
 |                     | **Vue-Games**                                                                                                                                                                                                                                                     | **Unity-Games**                                                                                                                                                                                                                                                                   | **Login-Frontend**                                                                                                                                                                                    | **Go-Backends**                                                                                                                                                                                                                                                            | **Spring-Backends**                                                                                                                                                                                                                                                        | **Docs**                                                                                      |
 |---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|
 | **How do we test?** | Classical                                                                                                                                                                                                                                                         | Classical                                                                                                                                                                                                                                                                         | Classical                                                                                                                                                                                             | Test driven                                                                                                                                                                                                                                                                  | Test driven                                                                                                                                                                                                                                                                   | At the latest to the sprint end the docs should be checked manually if the docs repo is up to date and correct. |
@@ -9,4 +11,4 @@
 
 
 
-For manual testing, a checklist will be created to ensure that nothing is forgotten.
+For manual testing, a checklist will be created to ensure that nothing is forgotten.
diff --git a/dev-manuals/asset-packs/README.md b/dev-manuals/asset-packs/README.md
@@ -8,4 +8,4 @@ every markdown asset pack file should follow the [template](asset-template.md) s
 
 ## assets
 
-- [Example Asset](asset-template.md)
+- [Zelda-like](zelda-like-tileset-and-sprites.md)
diff --git a/dev-manuals/asset-packs/asset-template.md b/dev-manuals/asset-packs/asset-template.md
@@ -2,6 +2,7 @@
 
 - Link to download/info site
 - Version: Version Number or Name
+- License: Info on License
 
 ## Used in
 

diff --git a/dev-manuals/asset-packs/zelda-like-tileset-and-sprites.md b/dev-manuals/asset-packs/zelda-like-tileset-and-sprites.md
@@ -0,0 +1,9 @@
+# Zelda-like tilesets and sprites
+
+- <https://opengameart.org/content/zelda-like-tilesets-and-sprites>
+- Version: February 16, 2017
+- License: <https://creativecommons.org/publicdomain/zero/1.0/>
+
+## Used in
+
+- overworld, worlds, dungeons
diff --git a/dev-manuals/design/README.md b/dev-manuals/design/README.md
diff --git a/dev-manuals/etc/README.md b/dev-manuals/etc/README.md
Original file line number	Diff line number	Diff line change
		@@ -1,4 +1,3 @@
		# Developer manuals

		Contains all information a developer needs to know to collaborate on a repo/ in this project.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -8,4 +8,4 @@ every markdown asset pack file should follow the [template](asset-template.md) s

		## assets

		- [Example Asset](asset-template.md)
		- [Zelda-like](zelda-like-tileset-and-sprites.md)