# Code of Conduct
| Date & Version | Changes |
| -------------- |:------------------------------------------------------------------------------------------------------------------------ |
| 18-04-2021 | Initial version |
| 19-04-2021 | Add William to member list; Minor lingual changes |
| 21-04-2021 | Clarify rotational structure of roles; Add roles; Add rest of team to member list; Add section on agreement modification; Add section on dealing with rule violations |

# Members
| Name | Number | E-Mail | Role |
|:--------------------- |:------------- |:-------------------------------- |:------------ |
| Valentijn van de Beek | [phone] | [e-mail] | Group Leader |
| William Narchi | [phone] | [e-mail] | Developer |
| Silviu Marii | [phone] | [e-mail] | Developer |
| Meeher Kapoor | [phone] | [e-mail] | Developer |
| Omar Thabet | [phone] | [e-mail] | Developer |

# Agreements
In the following sections we describe the various agreements, rules,
duties and rights that we promise to both abide by and uphold
throughout the duration of the project. First, we will sketch our
vision on what the goal of this project followed by a summation of our
agreements which we will round out by discussing some topics in
depth.

## Final Goal
Our overall aim throughout this project is two sided. One on a
technical, and another social. On the technical side our goal is to
write a well functioning bridge between the wind sensor and the
overall software infrastructure of the Autark Zero project using free
software. On the social side, we aim to create a professional
environment where all our members are treated with the respect that
they deserve and where everyone is open to chase their ambitions and
learn that which most interests them about this topic.

## General Rules
1. Everyone in the group shall at all times be considered equal to each other.
2. Everyone shall be treated with dignity, honesty, and respect.
3. Whenever there is a problem - personal or work related - this will be
communicated to the group in a timely fashion.
a) If a matter is private or if you would rather not have it shared
with the entire group, you can always communicate it to the group
leader who shall inform the rest of the group.
b) Any matter discussed with the group leader shall be confidential
and shall only be talked about in general terms by the group
leader. Breaking this rule is immediate grounds for removal.
4. The project group, and any associated digital platform, should be a
safe space for all members of the group. Ensuring an accepting,
tolerant and productive environment should therefore always be on
top of the mind
a) Any concerns about an unsafe environment should be communicated to
the group leader as soon as possible who shall take appropiate
measures.
b) There shall also be an external confidant any member can go to if
they would prefer that or if their problem is with the group
leader. This confidant can remove any member of the group to his
or her discretion.

## Group composition
1. The group shall consist out of five initial members.
a) A member can be removed or added from the group by an unanimous vote by the rest of the members of the group.
b) In case a member is removed they shall leave the meeting immediately and any access to digital resources shall be revoked.
c). Grounds for removal are, for example, racism, sexism, sexual misconduct, bullying, harrasment, repeatedly being absent or chronically not finishing tasks.
2. There shall be a group lead who shall be voted for during the first meeting.
a) A group lead can be removed by a majority vote in a meeting, in which case a new lead shall be chosen.
b) A group lead will chair meetings.
c) A group lead is the first point of contact in case of problems.
d) A group lead can speak for the entire project group.
3. There shall be a note-taker who takes notes during the meetings and who shall be assigned on a rotational schedule.
4. There shall be a scrum master who is in charge of the scrumboard and ensures that tasks are correctly added as well as updated. Similarly to the note-taker, they shall also be assigned on a rotational schedule.

## Meetings
1. There shall be a meeting at least once a week
2. A meeting is mandatory
a) In case you can't make it, communicate to the group lead at least two hours beforehand.
b) Missing three meetings without adequate reason is grounds for removal.
3. The group lead shall post an agenda for the upcoming meeting at least six hours before it starts. All members can ask for modifications to this agenda.
4. The company contact, TA, and mentor are always welcome. Other externals can request access on the agenda post.
5. Some parts of the meeting can be labeled as confidential in which case non-group members need to leave.

## Communication
1. Communication shall happen over Discord, Mattermost or Discourse.
2. Discourse is the primary source of information and the place where the project ought to be documented.
3. Meetings are either held online, Jitsi, Zoom, Discord, or physically.

## Quality Control
1. Development is done on a university-hosted GitLab instance using branches and pull requests.
2. Every feature shall be developed in a separate branch.
3. Every merge request shall have an adequate level of documentation and shall at least summarize the changes as well as indicate why they have been made.
4. During the project we shall aim to always make use of the most common style guide used for a particular programming language.

## Group Decision-making
1. Small-scale decisions confined to a subset of the group should be negotiated between the relevant members and only escalated in case of time-critical decisions or if a consensus cannot be reached between the relevant members
2. Large-scale decisions affecting the project significantly (or escalated small-scale decisions as outlined earlier) shall be carried out in the following manner.
a) Attempt a vote using [instant-runoff voting](https://en.wikipedia.org/wiki/Instant-runoff_voting)
b) If step (a) fails, the group leader's vote is counted double on the condition that they must then consult with their choice of client, supervisor and/or TA and then schedule another meeting where a new vote is attempted

## CoC Modification
1. Incorrect information should be amended when possible; a vote on this is not necessary, but every member will be informed about the change(s).
2. Whenever someone feels that we need a new rule that could potentially improve the workflow we will discuss it during the next meeting.
3. Similarly, lingual mistakes - such as grammar, spelling, et cetera - should be amended when they're spotted and do not require communication with the rest of the team.
4. Potential shortcomings or desired alterations should be proposed to the rest of the group members and only implemented if unanimous agreement is reached.
5. Any changes made should be documented in the table at the top of the document. Changelog messages need not be very detailed, but should convey the main change(s), similarly to Git commit messages.
6. Changes should be grouped by date.

## Breaking CoC Rules
1. For rules whose violation is not grounds for being immediately kicked or suspended, a three-strike system shall be adopted. On accumulating three strikes, the other team members will convene to decide on a suitable punishment given the violator's actions. Final rulings require TA approval.
2. In addition to the above outlined procedure, upon accumulating a strike the violator is required to provide a form of symbolic apology. This can include, but is not limited to the following.
a) Provide some form of food for the whole team in the next physical meeting (ideally sweet)
b) Organise a gaming night (perhaps recurring)
3. In case of a violation that constitutes grounds for removal from the group or similarly harsh punishment, the parties affected should bring the matter to the attention of the confidant, who will then take the necessary steps to carry out the punishment

## Financial
TBD