# Code of Conduct

###### tags: `assignment` `planning`

**Assignment description:**
**In your own words, describe what you need to do as a group in this course.**
We will be directed towards forming a supportive and efficient group dynamic, resulting in quality meetings and quality work. In order to achieve this, not only we all need to make sure we are always on the same page, but we need to find a balance between individual work and group work. We all need to learn how to collaborate in an efficient and productive manner, while also taking individual responsibilities.

## Target or ambition level:
**What grade are you working for?**
We are working for a 10 and a good impression in the company.

## Products:
**What should you deliver at the end?**
The final product should allow the user to input a collection of reviews into the application and have it return a clear visual representation of what categories are talked about and if there is a positive or negative sentiment towards them.

More specifically, following the client's requests, we will categorize the reviews based on hand-picked concepts and allow for review filtering on such classes. The output will be in graphs and text format. To achieve this we will use Python to develop the Machine Learning model, and JavaScript with React for the visual output of the results.

Furthermore, we will abide by the TU Delft requirements for the project, completing all assignments in due time.

**On which platform do you share which documents (Discourse/Miro/MS Teams)?**
We use the following platforms:
- Gitlab to share and review the actual code.
- Hackmd.io for assignment
- Notion for meeting notes and agendas, and other generic text notes

**What standards must the work submitted meet?**
For code to be up to standard, it must be:
- Reviewed by at least two other members of the team before merging.
- Throughly commented, in order for other users to quickly grasp what the code is doing.
- Optimize the code for performance.

For text related collaborative work to be up to standard, it must be:
- Read, commented and understood by the entire group before submission.
- Completed at least two days in advance to allow for revision and fine tuning.

## Planning:
**How do you ensure that each group finishes everything on time?**
We have weekly sprints where we divide tasks evenly depending on everyone's preferences and availability. On top of this, we will have daily standup meetings on weekdays to ensure everyone is on track, or explore what is causing the delay and how to remedy it.
Moreover, we will hold slightly longer midweek sprint meetings during phases where we believe the backlog contains many short-term and unpredictable tasks. This will ensure that people with unpredictably easy tasks will be able to continue working on other things, and, similarly, tasks that unexpectedly require more time will be restructured into multiple sub-tasks, or further divided amongst the team members, or any other solution deemed fit.

**Did you clarify who will have a final say in the final deliverable and submits it to Brightspace on behalf of the project group?**
We will be using majority vote for final decisions. In the event of a tie, we give our Scrum Master (Kristof) the authority to make the final call. For submissions, we make sure to submit it all together after the final tuning has been completed.

## Behavior:
**How do you treat each other in the group?**
First and foremost we treat each other with respect, which means:
- We give everybody the opportunity to express their opinion.
- We do not interrupt, nor dismiss anybody's idea without reason.
- We ensure after every meeting that everyone felt heard and understood, and if not, we strive to express our concerns and tackle them before, or during, the following meeting. This will be facilitated by our meeting review form.

**How do you handle disagreements within your group?**
Since disagreements are natural, we aim to create an environment where everybody can express their opinion. Our current method of achieving this is enforcing that only people that raise their hands and are appointed can speak. Once everyone has expressed their opinion and the discussion is over, if there is still no consensus, we will use majority voting. In the event of a tie, we give our Scrum Master (Kristof) the authority to make the final call.

**Could your guide or student assistant be involved in reaching consent?**
We believe the input of the SA and coach is extremely useful, especially when dealing with uncertainty within the group. As such, we will definitely utilize the help we can get to ensure we learn the correct steps in resolving a given issue. This issue could be a technical or a project structure issue.

**What do you do if someone is late during a group meeting?**
If someone is more than 5 minutes late for a meeting more than 3 times, we will first discuss what is causing the continuous lateness and aim to fix it, and additionally we have agreed that they will then buy snacks for the entire team at the next meeting.

## Communication:
**In what ways do you communicate with each other as a group and among yourselves? (in the studio/MS Teams/Miro/Discourse)**
Our main communication is based on:
- Google calendar for communicating and tracking events.
- Mattermost to connect with the course staff, namely the teaching assistant and the coach.
- Slack to contact the clients and for more formal communication between team members.
- Whatsapp for informal friendly communication.

## Commitment:

**How do you determine the quality of each group's work, so that each group delivers the same quality?**
We consider published work to be of good quality if it meets the above stated quality standards.

**How do you measure the commitment of the chairs and minute takers?**
For the chair: using the meeting retrospective document (checking if the meeting has been completed efficiently and without forgeting any details).
Minute takers: whether or not they have captured all relevant information from the meeting.

## Meetings:

**How often will you meet as a group?**
We have a complex meeting schedule on google calendar.
Since we use SCRUM, we will have sprint planning, sprint retrospective, and daily standup meetings.

| Day | Column 2 |
|:--------- | ------------------------------------------- |
| Monday | Halfway Sprint meeting 18:00 |
| Tuesday | TA meeting 09:30, standup straight after |
| Wednesday | Standup 09:30 |
| Thursday | Sprint retrospective: before meeting with client, Client meeting at 11:00, sprint planning right after |
| Friday | Standup 09:30 |
| Saturday | |
| Sunday | |

**What preparation is needed for the meetings?**
For the **daily standups** we expect everyone to be able to say what they've been working on or having issues with, and what they are going to work on until the next meeting.
**Client meeting:** Everyone can present what they've been working on in a demo. The meeting agenda will be agile and adapt each week to the work done. This will be prepared and majority accepted before the meeting.
**Sprint planning:** The scrum master checks if the backlog is accurate and if there are sufficient tasks for the following weeks.

## Decision-making:

**How do you make decisions? By majority vote or by consensus?**
We will have open discussions about the topic, and if we do not reach consensus then we will use majority voting. In the event of a tie, we give our Scrum Master (Kristof) the authority to make the final call.

## Dealing with conflicts:
**How do you handle conflicts within the group?**
Opinion conflicts will be discussed during the meetings as a debate between members. At the end all members will vote on the final decision.
Harsh verbal conflicts will not be tolerated and result in a strike (look in "Consequences")
Physical conflicts will not be tolerated and result in 3 strikes (look in "Consequences")

## Guidance:
**What do you expect from the teacher's and/or student assistant’s guidance? What do you want feedback on, on the content or on the collaboration?**
We expect weekly feedback on our way of working such as,
- If our Gitlab contains all the necessary information for that week.
- Any new information from the course's organizers that we aren't able to retrieve from any source.
- If we are falling behind on the schedule.

## Consequences:
**What are the consequences if a participant in the group does not keep the agreements?**
We will keep a system of strikes. The penalties are the following:
- Showing up late to a meeting by more than 10 minutes without announcement: 1 Strike
- Showing up late to a meeting by more than 15 minutes without a valid reason: 1 Strike
- Not showing up to a scheduled meeting without announcement: 2 Strikes
- Missing on a meeting with the client without announcement: 3 Strikes
- Not finishing a required task on a due date, without asking for help: 2 Strikes
- Missing on a meeting with the TA without announcement: 3 Strikes
- Fighting between members: 3 Strikes

After 3 strikes there will be put an extra workload of 8 hours on the defendent by assigning him/her more tasks the next week.

## Success factors:
**What makes your team a dream team?**
- We are a perfect suit for the project required. We are 3 AI engineers and 2 front-end developers.
- We will try different ways of communicating between members in order to find the perfect suit.
- We made a rigid timetable and a set of sanctions to ensure that no deviations are permitted.
- We are a dedicated, ambitious and enthusiastic group interested in learning more about the subject.

## Extra useful stuff for us

### Gitlab
1. Every pull request should have passing pipelines.
2. The pipelines include:
- build/compilation phase,
- test phase,
- linting phase (python checkstyle)
4. We will have different branches for each issue/task/feature 'issues branches'
5. The issue branches will be named descriptively:
- starting with the issue number
- followed by the issue name connected with hyphens
- example: 1305-creating-basic-report
6. We will have different branches for each sprint, we first do a PR into that branch for the issue branches. When a sprint is over, we merge the sprint branch into main.
7. At least one code review on pull requests.
- Seriously
- We will do code reviews
- Yes. Do it. You know you want to.
- Good code = Happy mode

### Meetings
Every member should come to a meeting prepared with:
- A set of questions/remarks
- Be able to answer the question: "What did you work on this week?"
- If help is needed, the person is required to make a subtask of his task as well as an estimate of time for it.

Every meeting will be composed of:
- A note taker, responsible to take notes during the meeting and push them on gitlab afterwards.
- A Chairman, responsible for keeping the agenda and come up with the requirements for this week. Whoever has the most content can take the lead in the meeting.