# Code of Conduct

## Shared team values

1. Quality: We care about making the best product possible.
2. Communication: We believe it’s of utmost importance to have good communication, by being reachable, honest, and transparent
3. Respect: All team members should always be respected
4. Helpfulness: We want teammates to help other teammates when they are stuck
5. Learning: We want to leave this experience having learned how to work in a team and practical applications of software engineering
6. Leadership: We want to have some people making sure that there is a high-quality process for the development

## Assignment description

For this course, the main goal is to develop a toolkit for speech analysis for the Multimedia Computing group. To complete this part successfully, we will keep closely in touch with the client to ensure that their requirements are fulfilled. This will be done through weekly meetings with the client. Furthermore, we need to create a final report following the guidelines from the Technical writing course. We will ensure that the report will be finished on time by following the deadlines on bright space closely, to complete them up to our desired standards. This should ensure that most of the parts will be finished before the final deadline crunch.

## Target or ambition level

Ideally, of course, we want a 10. However, the grade that we have decided we would all be very happy with is a 9. We would prefer not to go below an 8.

## Products

In the end, we should deliver a web application that can be accessed on the website [spectral.ewi.tudelft.nl](http://spectral.ewi.tudelft.nl/). It will be hosted on a TU Delft server just like the kernel and documentation website that we will create. The code will be stored on both the EEMCS Gitlab server and Github, where the goal for Github is to open-source the project.

We will also have to create a final report about the project that will be handed in on Brightspace. We will create this report throughout the project by handing in the sub-assignments on Brightspace as well. We will work on the report using Typst, which allows us to work on the project together in real-time.

Any deliverable should at least meet the requirements of the assignment and should have been checked completely by at least 2 people to ensure that all requirements are met and that the deliverable is of high enough quality.

## Planning

We all have hard deadlines provided by the Software Project course. We need to always abide by these. Furthermore, we will have many internal deadlines. These can be of many forms.

First of all, we have a general deadline for finishing the implementation of the project as soon as possible. Namely, we want to be *mostly done* by the start of June. Of course, what “mostly done” means can be up for debate, and similarly with “the start of June”. This is a very soft deadline, but we are aware of it as a team and we will take reasonable actions to try to maintain it.

The main form of internal deadlines is in the form of GitLab issues. Each issue gets assigned a person and a date. Issues that are expected further down the line are susceptible to changes. The assignee can also change depending on the workload of each and the difference between the expected and actual difficulty of a task.

However, we do expect each person to do something, so if a team member continuously tries to push off tasks we will not allow them to do so. If the lack of cooperation gets too large, it can theoretically escalate to the point of contacting the SP coordinators to see what action can be taken, such as expelling the member from the team (of course, we believe it is extremely unlikely for this to happen in our team).

For group deliverables, each person has a say and can propose concerns with the current state of it. We want to resolve most of them by consensus, but if this can’t be realized then we will use a majority vote.

Roman Knyazhitskiy will be the responsible and de facto person to hand in deliverables on Brightspace on behalf of the project group. However, we will allow somebody else to upload it if everybody agrees, which is a somewhat common situation. We will have a rule that there needs to be *something* submitted to Brightspace at least 2 hours before the deadline, to make sure we don’t leave it blank. We can always resubmit a newer version after the deadline.

## Behavior

Within the group, we treat each other with respect. We handle disagreements within the group by listening to each other's arguments and picking the best option based on those arguments. In case there does not appear to be a clear best option, a majority vote will be applied, which in the case of a dichotomy should lead to a decisive decision since we have 5 group members.

If, for whatever reason, this does not work out we can always go on to the next step, which is to discuss the best solution with another party. Depending on the problem, this other party could be the TA, the coach, the client, or possibly the course staff. Hopefully, through the use of their guidance, we will be able to come to a consensus.

Furthermore, if someone is late for a group meeting, we will be quite lenient for the first couple of times. In case it does appear to be a pattern, a reasonable punishment will be applied to discourage this behavior, i.e. bringing in some snacks for the others. If the behavior does not improve, or someone stops joining meetings without any good reason, then further punishments will be discussed with the TA.

## Communication

Within our group, we mostly communicate via WhatsApp, Mattermost, Zoom, Discord, Gitlab, Outlook, and in real life. We mostly use WhatsApp for general discussions regarding our project, which includes things such as setting up meetings amongst ourselves, telling someone to look at a merge request on Gitlab, etc. Gitlab will be used for sharing our code and discussing code-related issues or ideas. We will also track our progress together on GitLab and plan out what we will work on during the next sprint. We use Mattermost and Outlook mostly to communicate with the client, coach, and TA, which includes tasks such as setting up meetings and asking questions. Last of all, we use Zoom during meetings with the client, TA, or coach in case one of us is unable to attend in person and Discord if we have an online internal meeting, which could be a work session for instance. And last of all, we do in-person meetings, in which we work and discuss.

## Commitment

The quality of the work from our group will be determined by evaluating our work according to the rubric. This evaluation we be done before the midterm, in weeks 7, 8, and 9. The work of each team member will also be looked at, which will be done at the end of each sprint, in our sprint retrospective. During the sprint retrospective, we will go over the work each member has done what they did well, and what they could improve. This evaluation will also make some use of GitLab features such as activity (using, of course, reasonable judgment and common sense, since some of these stats can be misleading and/or easily tricked).

A measurement of the commitment of the chair can be based on 2 moments. First of all, the chair is responsible for ensuring that everyone is present at the meeting, which includes setting a date and location for the meeting. Secondly, the chair’s commitment can be measured during the meeting. During the meeting, the chair's main responsibility is to ensure that the meeting stays on topic and that everyone has the opportunity to share their thoughts if they have any. If the chair succeeds on both of these points, then the commitment of the chair is great. If something goes wrong in either phase, then this will be discussed during the next internal meeting to ensure that it goes better next time.

To measure the commitment of the minute taker, we will mostly look at whether the meeting notes are complete and if no important details were left out. If we do believe that the notes were lackluster, then this will be discussed during our internal meeting.

## Division of tasks and roles

The role of the chairman will be covered by Roman, as he naturally has good team-leading skills as well as a good amount of on-the-spot thinking that helps us coordinate our team better, which makes him the perfect fit for this job. If Roman is unavailable to attend, then anyone else who is willing to take his spot is sufficient for our purposes.

The role of a minute-taker will be cycled with every meeting, with Roman being excluded from this cycle due to his chairman role, as follows:

- Thijs
- Quinton
- Odysseas
- Yousef

We believe that having a cycle and excluding Roman from the role of minute-taker would make it the fairest for the team. The minute-taker cycle is not strict, we are flexible to modify it depending on the situation of each meeting (e.g., battery life, keyboard, whether the person is online, etc.)

## Meetings

During the project, many meetings will have to be arranged for several purposes.

The team will be meeting at least once a week to do sprints, thus making sure everyone is on track and that the development of the project is going as planned. If agreed upon by all of the team, then more meetings can be arranged internally to discuss deliverables or any other subject that is required.

Moreover, we will have a weekly meeting with our student’s assistant to ensure that we are doing well in terms of collaboration and grades.

In addition, a meeting with the client will happen once a week to discuss progress and possible changes to the project.

Meetings with the coach will happen periodically, if necessary: since our coach is a busy person, we would like to not disturb him with insignificant problems. However, we will attempt to have a meeting with the coach on every significant milestone, and we will try to keep him informed about the general progress of our project. We expect to have biweekly meetings.

To ensure that we are organized during every meeting, we will have agendas that specify talking points. The agendas will be created in order of the following list, looping back when everyone has done everything:

- Yousef
- Odysseas
- Quinton
- Thijs
- Roman

After an agenda has been created, it should be put as a merge request in the documents repository, where people in the team can add/change points that exist through comments. Finally, after one day of the merge request being up, it should be merged into the repository.

## Decision-making

Decisions can be classified into 2 different categories: minor and major

Classification of a decision is made with a majority vote, or simply implied in clear-cut cases.

Given a minor decision to be made, we will do a majority vote, since a minor decision is not significant enough to warrant a long discussion and convincing.

Given a major decision to be made, we will *try* to get a consensus. This would involve making sure that every member of the discussion fully understands the details of the decision. Afterward, everyone would discuss their point of view for the decision. If there is yet to be a consensus after it is thoroughly discussed, then a majority vote would take place.

In conclusion, our decision-making strategy should promote not only communication but also fast resolution, depending on the “severity” of the decision.

## Dealing with conflicts

Conflicts and decisions should be handled very similarly, and thus have a similar procedure to follow.

A conflict within the group can be classified as either minor or major, which is either trivially identified or explained by a team member.

Regardless of the type of conflict, there must be some form of discussion that has to take place, so that each team member is content with the resolution. Depending on the severity of the conflict, more research should be done and a longer discussion should be had. If either side of the conflict is not completely satisfied with the resolution after the collective team meeting, the conflict is going to be lifted to the level of a student assistant, which is going to hopefully resolve the issue. If the TA is also not able to help with the conflict resolution, or either side is still not satisfied with the resolution, the conflict is going to be lifted to the level of the course stuff, and we are going to attempt to resolve the conflict by emailing the course stuff. Further escalation is possible with the help of the course stuff if needed.

## Guidance

We expect to get help from both the student assistant and the coach for our project.

From the student assistant, we would like to receive help with collaboration. Meaning how well we are collaborating, things that we can improve on in terms of collaboration, etc. We also expect some indication on course matters, such as what it is expected from us, whether we are allowed to do certain actions, setting up some privileged GitLab settings, etc.

From the coach, we would like to receive help with the content. This means receiving feedback on the content of our documents, feedback on our application (since in our case the coach also has an extensive amount of knowledge/experience in the field of the application we are planning to make), etc.

## Consequences

If a member does not keep to the agreements, then we will ensure to discuss it in our next internal meeting. During this, we will make sure to highlight what action infringed our agreements and what could be done to prevent future infringements.

If this behavior keeps persisting regardless of our warnings and feedback, then we would be forced to talk to someone of higher authority for them to guide us, or if that doesn’t work either then for them to intervene. The person of higher authority should start from the TA, go to the coach, and finally the course coordinators.

## Success factors

Our team has many qualities that make it a clear dream team.

A crucial quality is communication. We are very talkative with each other, which allows for easy conflict resolution and efficient decision-making. Essentially, it boils down to us feeling free and not shy to discuss anything regarding the project. In addition, we encourage each other to participate in our decision-making.

Moreover, we all have a good amount of knowledge in different subjects, which helps to enlighten everyone in the team with our perspective. As a team, we can solve problems in many different ways, improving our efficiency.

And, of course, we care about the project and building a good product. We are motivated and we want this project to be something to be proud of. We are not very far removed from the users of our software, which makes it all the more encouraging to build something that these people will find joy in using.

## Norms or evaluation criteria

1. Communicative
2. Keeps deadlines
3. Effort put into learning
4. Hard-working
5. Willingness to help others when in need
6. Good attitude toward project/teammates
7. Willingness to propose novel, disrupting solutions
