docs: code of conduct v2
This commit is contained in:
parent
4fb216373a
commit
ac5491dbb3
1 changed files with 41 additions and 33 deletions
|
|
@ -1,54 +1,62 @@
|
||||||
# Code of Conduct CSEP
|
# Code of Conduct CSEP
|
||||||
> Last changed: 2025-11-14 04:20 PM
|
> Last changed: 2025-11-27 10:30 PM
|
||||||
## Assignment description
|
## 1. Assignment description
|
||||||
- Working on our teamwork skills "by helping eachother and working with eachother"
|
- Working on our teamwork skills by helping and collaborating with each other.
|
||||||
- Coding with other people "by working together in gitlab and in person"
|
- Coding with other people through the use of Git + GitLab tooling.
|
||||||
- Communication skill in a group setting "working in a project with 6 people"
|
- Communication skill in a group setting working in a project with 6 people
|
||||||
|
|
||||||
## Target or ambition level
|
## 2. Target or ambition level
|
||||||
- So we working towards a 10 but a 8 is fine
|
- Goal is at least an 8/10, aiming for a 10.
|
||||||
- The most important thing is that everyone does their best
|
- The most important thing is that everyone does their best
|
||||||
|
|
||||||
## Planning
|
## 3. Planning
|
||||||
- We will at least meet in person 2 times a week with preference to thursday and friday
|
- Meet in person minimally 2 times a week with preference to Thursday and Friday
|
||||||
- We will meet 1 time a week online on monday
|
- Meet 1 time a week online on monday
|
||||||
- We will have an organic planning with code because we will need to see week to week what we can do and what we can achieve
|
- We will adjust expectations and deadlines dynamically depending on what has been actually achieved in the previous week, during one of the aforementioned meetings.
|
||||||
|
- During a pre-meeting session in the CSE1105 labs on Friday, we will:
|
||||||
|
- discuss any development blockages that team members encountered during the week.
|
||||||
|
- go over open MRs.
|
||||||
|
- plan any task items for the next week.
|
||||||
|
- consider potential additions to the week's agenda.
|
||||||
|
- **Submitter of any Brightspace material** - Rithvik Sriram
|
||||||
|
|
||||||
|
## 4. Communication
|
||||||
## Communication
|
- Discord for our online meeting and sharing info and asking questions.
|
||||||
- Discord for our online meeting and sharing info and asking questions
|
|
||||||
- GitLab to share our code
|
- GitLab to share our code
|
||||||
- Thursday and Friday lab meetings for in person meetings
|
- Thursday and Friday lab meetings for in person meetings
|
||||||
|
|
||||||
### Collaboration outside of the mandatory meetings
|
## 5. Collaboration outside of the mandatory meetings
|
||||||
- Thursdays (to code together and help eachother)
|
- Thursdays (to code together and help eachother)
|
||||||
- Friday during lab before ta meeting (to make the final changes before merging)
|
- Friday during lab before ta meeting (to make the final changes before merging)
|
||||||
- Discord (for our quick questions about the small things)
|
- Discord (for our quick questions about the small things)
|
||||||
- GitLab
|
- GitLab
|
||||||
|
|
||||||
## Help and assistance
|
## 6. Help and assistance
|
||||||
- We have discord together, so if there is a question or issue it can be asked there and also during the friday meeting
|
- Reserving Discord as a method of communication through which anyone who has an issue or question can talk.
|
||||||
- If someone is really struggling we make sure to help them in person based on the part they're working on client or server
|
- A person who is having trouble with implementing a specific part of the software is ensured to have another team member available who can assist in debugging/guiding the implementation of that particular feature.
|
||||||
|
|
||||||
## Work quality
|
## 7. Work quality
|
||||||
- By having the other 3 members rate the code on gitlab
|
- Each Merge Request is required to:
|
||||||
- Making sure we use the same checkstyle document
|
- have at least approval from one person responsible for backend, and one person responsible for frontend.
|
||||||
- Making sure we also talk about what we want to see in the form of comments + style of code
|
- concern only one feature/issue, to ensure atomic MRs/commits.
|
||||||
|
- have generally atomic commits, aka. frequent and small, such that any issues introduced by one specific commit can be triaged quickly.
|
||||||
|
- Comply to the existing CheckStyle document (enforced automatically via Maven build server).
|
||||||
|
- have clear comments and JavaDoc written wherever non-trivial functionality is involved.
|
||||||
|
|
||||||
## Decision-making
|
## 8. Decision-making
|
||||||
- Discuss it with arguments so consensus
|
- Important decisions within the group, such as major refactoring or design decisions, will be decided within the group by way of consensus.
|
||||||
- Using polls for our meet up location or decisions that are yes or no
|
- Decide on where and where to meet during the week by way of Discord polling.
|
||||||
- If someone want to change something they have to bring up the arguments for why the change is good
|
|
||||||
|
|
||||||
## Broken agreements
|
## 9. Broken agreements
|
||||||
- If someone breaks the agreements we have agreed upon in this code of conduct we will first of all discuss it with them
|
- If someone breaks the agreements we have agreed upon in this code of conduct we will first of all discuss it with them
|
||||||
- If someone isn't collaborating at all we will make this clear to the TA and hope they can help
|
- If someone isn't collaborating at all we will make this clear to the TA and hope they can help
|
||||||
- If that doesn't resolve it we will bring it up with the lecturer
|
- If that doesn't resolve it we will bring it up with the lecturer
|
||||||
- Never will we just exclude someone without taking the proper step
|
- Never will we just exclude someone without taking the proper step
|
||||||
|
|
||||||
## Problem resolution
|
## 10. Problem resolution
|
||||||
- We are all adults here so we can just talk it out by civil discussion
|
- Main way of problem resolution is by reasoning and team discussion in good faith.
|
||||||
- If your gonna be late, communicate with the rest of the team
|
- If a team member is not able to, or will be late to, a specific meeting, this should be communicated at least 1 full day before the meeting's commencement.
|
||||||
- Give a reason if you can't show up for a meeting
|
- For major issues and problems for which the above methods cannot suffice, the responsible chair during the week in which the issue occurred will consult third parties in order of increasing severity:
|
||||||
- Contact with the TA will be needed when someone doesn't react to any of our messages and doesnt show up at all
|
1. discuss the issue with the TA.
|
||||||
- Never escalate any problem if there is a big problem discuss it with the TA or lecturer depending on the severity of the problem
|
2. communicate with the CSE1105 teaching team e.g. by form of email.
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue