# Group contract for Bachelor's thesis

A document clarifying how work in the project will be done.

## Group member contact information

| Name | Mail adress | Phone number |
|:------------------- |:------------------------------- |:------------ |
| Martin Jonsson | [e-mail] | 0793407009 |
| Mathias Prétot | [e-mail] | 0706309103 |
| Jacob Bredin | [e-mail] | 0723693160 |
| Christoffer Persson | [e-mail] | 0720338425 |
| Linn Österlund | [e-mail] | 0707741712 |
| Edvin Nilsson | [e-mail] | 0727185767 |

## Cooperation rules

Which rules we have agreed to follow during the project.

### General communication

* Slack
* Zoom for remote meetings

### Meetings

* Booking
* Booking for the next will be done at the end of the previous meeting.
* A booking responsible will book rooms for these meetings.
* Mathias is booking responsible.
* Meeting procedure
* Meeting minutes for the next meeting will be created at the end of the previous meeting.
* A Keeper of The Minutes will fill out a preliminary agenda.
* Everyone will be able to add to this agenda, it will be available in hackmd.
* The meeting will proceed (mainly) according to this agenda.
* At the end of the meeting, a clear assignment of tasks is done and recorded.
* The time and place for the next meeting should always be clear at the end of the previous meeting.
* [Template for meeting minutes](/vE-4lGDjQlWRRivKTp7qTw)
* Presence
* The group members present will be recorded in the minutes.
* Late arrival
* Should be avoided, but not the end of the world if you're late.
* Try to notify on Slack when you know you will be late.
* The meeting starts at the designated time. If someone is always late, then the time of the meeting should be changed instead of waiting for them.
* The ones present at the meeting can decide to wait for the ones who are late.
* When?
* We have two default meetings every week (monday, friday), but these times can be modified depending on circumstances.
* Booking responsible will be responsible for making sure all meetings are added (time and place) to the shared Google Calendar. Any meetings not recorded in this calendar are not decided.
* The meetings will be on-campus, but if necessary group members can join remotely.

#### On failure to comply

* See escalation plan.

### Work plan

* Prototypes
* We will create prototypes for the different parts of the project during the initial stages. These will be limited to the first few weeks of the project, in order to avoid "integration hell" later on.
* These will be used to individually explore different parts of the project.
* Exploration individually or in small groups
* Tasks can be assumed by individuals or small groups during monday meetings, where they will have the "mission" of exploring a topic until the next meeting.
* Working hours
* The goal is to contain all work to normal working hours (mon-fri 8-17), but working outside of these hours is allowed by individuals if they want to.
* Each group member should be reachable during working hours (e.g. you should check the Slack at least once a workday).

### Workload

* Areas of responsibility
* These roles do not mean that the assigned person is solely responsible for that area. We as a group are still all responsible, but that person is mainly responsible.
* Booking responsible: Mathias
* A booking responsible will book rooms for meetings and make sure the shared calendar is updated.
* File hoarder: Christoffer
* Is responsible for making sure all of the required documents are accessible by the examination team through Canvas.
* Project diary responsible.
* External communicator: Jacob
* Responsible for communication with examination team.
* External communication should be relayed to the entire team.
* Should keep track of deadlines and changes relayed through Canvas from examination team.
* Group leader: Martin
* Runs the meetings.
* Makes sure the project progressing.
* Final say during controversial decisions.
* Keeper of Minutes: Linn
* Takes notes during meetings.
* Report responsible: Linn
* Responsible for making sure the report is making progress.
* Makes sure the report is well-written.
* Makes sure the report follows all requirements.
* Code responsible: Edvin
* Makes sure the code is well-documented and well-written.
* Assignment of tasks
* We do a trial period of using "Kanban" with GitHub projects. We will have a board with a backlog of prioritized issues. These issues will be "groomed" by the team at the monday meetings.
* At the monday meeting, everyone should have an issue to work on.
* An "issue" is any unit of work, like writing a feature in code, researching something, or writing something in the report.
* Issues are not assigned (push), they are selected (pull) by each team member whenever they have completed their current issue.
* To maintain code quality, every "code-issue" should be worked on in its own separate branch, then a pull request should be submitted, then this PR should be reviewed by 2 other group members before finally being merged into master.
* Code review should be prioritized above everything else when you start your work session. If a PR is submitted while you are working on something, you don't have to drop everything and review it.
* The reviewer is expected to at least skim through the code, and should have a basic understanding of the new functionality. If the reviewer does not understand part of the code, then they should have a meeting with the author.
* Deadlines
* External project deadlines are paramount. We should have internal deadlines a bit before these actual deadlines.
* A check-up is done a week before external deadlines, to discuss progress.
* Important deadlines (individual and group) should be reminded of during meetings.
* Each issue should be small enough that it can be completed within a week, and if this is not the case then the issue-holder should notify the team.

#### On failure to comply

* See escalation plan.

### Decision making

* When will majority decisions, consensus or decision distribution be used?
* We should strive to have every decision be made in consensus.
* When a consesus can not be reached, we will defer to the group member responsible for that part of the project. If there is no one responsible for an area, or if the one responsible can't make a decision, then the project leader makes a decision.
* No decision should be made unmotivated.
* The group contract can not be changed without the approval of every group member.
* If someone is not present at a meeting, they lose the right to take part of these decisions. If someone who did not attend the meeting does not agree with decisions made, they can make comments on Slack and discussion can be had. If no resolution is made during the discussions, the decision will be the same as was taken during the meeting.

* Documentation of decisions
* Decisions are not valid if they are not written down in the meeting minutes.
* Smaller decisions can be made on Slack, on the next meeting they must be written down to be valid. The one making the proposal is the one who should add it to next meeting's minutes.

#### On failure to comply

* See escalation plan.

### Project diary and contribution report

* How, who & when?
* Time logging will be done daily in a shared [Google Sheet](https://docs.google.com/spreadsheets/d/1uMeB7JeHRCZX5Orbsb6DmTpcR_OjFQGGbDJIPjIuwd8/edit?usp=sharing).
* The contribution report should be updated continously in [this markdown file](/L4RI0rM1STaejiVBN2n4CA).
* The project diary will be filled in weekly at the friday meetings, and is located in [this markdown document](/UUpErZVmSh-OlvOvXIYzzw). Christoffer writes in the diary based on what has been discussed during the friday meetings.
* These markdown documents are pushed to the GitHub-repository every friday.
* Praise and criticism
* Can be done during PR reviews.
* If it becomes a problem, we will discuss it further down the line.
* Breaking the contract ("escalation plan")
* Step by step escalation guide.
1. Speak with the concerned group member(s). Understand the situation.
2. Try to find a solution or try to convince them to change their behaviour.
3. Inform the supervisor/ examinator about the issue.

#### On failure to comply

* See escalation plan.

### Document and file management

* How, who?
* All the documents will be in English.
* The report will be written by everyone in $\LaTeX$ using [Overleaf](https://www.overleaf.com/project/63b82f97e8e8511fdcfe74ad).
* Google Sheets is used for the time log, which is updated by each group member individually.
* The remaining documents are written in Markdown using HackMD, and synchronized to our GitHub-repository.
*
* Version control
* We will use Git and GitHub.
* We will follow this [Git Workflow](/sk-Aj6CfRmSc_4AAS1bPQw).

#### On failure to comply

* See escalation plan.

## Ambition

Our goal is to create a functioning and fast ECS engine. We aim to write a comprehensive and high-quality report. More details in the [Project Plan](https://www.overleaf.com/project/63c6986286fd078e44b2407f).

| Name | Moderate | A great deal | A very great deal |
|:----------- | -------- |:------------:|:-----------------:|
| Martin | | | X |
| Mathias | | X | |
| Jacob | | | X |
| Christoffer | | X | |
| Linn | | X | |
| Edvin | | | X |

We are aiming towards a five but most of all we aim towards being proud of our work.

## Signatures of all group members

Jacob Bredin
Christoffer Persson
Martin Jonsson
Linn Österlund
Edvin Nilsson
Mathias Pretot