62 lines
3.6 KiB
Markdown
62 lines
3.6 KiB
Markdown
# Code of Conduct CSEP
|
|
> Last changed: 2025-11-27 10:30 PM
|
|
## 1. Assignment description
|
|
- Working on our teamwork skills by helping and collaborating with each other.
|
|
- Coding with other people through the use of Git + GitLab tooling.
|
|
- Communication skill in a group setting working in a project with 6 people
|
|
|
|
## 2. Target or ambition level
|
|
- Goal is at least an 8/10, aiming for a 10.
|
|
- The most important thing is that everyone does their best
|
|
|
|
## 3. Planning
|
|
- Meet in person minimally 2 times a week with preference to Thursday and Friday
|
|
- Meet 1 time a week online on monday
|
|
- 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
|
|
- Discord for our online meeting and sharing info and asking questions.
|
|
- GitLab to share our code
|
|
- Thursday and Friday lab meetings for in person meetings
|
|
|
|
## 5. Collaboration outside of the mandatory meetings
|
|
- Thursdays (to code together and help eachother)
|
|
- Friday during lab before ta meeting (to make the final changes before merging)
|
|
- Discord (for our quick questions about the small things)
|
|
- GitLab
|
|
|
|
## 6. Help and assistance
|
|
- Reserving Discord as a method of communication through which anyone who has an issue or question can talk.
|
|
- 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.
|
|
|
|
## 7. Work quality
|
|
- Each Merge Request is required to:
|
|
- have at least approval from one person responsible for backend, and one person responsible for frontend.
|
|
- 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.
|
|
|
|
## 8. Decision-making
|
|
- Important decisions within the group, such as major refactoring or design decisions, will be decided within the group by way of consensus.
|
|
- Decide on where and where to meet during the week by way of Discord polling.
|
|
|
|
## 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 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
|
|
- Never will we just exclude someone without taking the proper step
|
|
|
|
## 10. Problem resolution
|
|
- Main way of problem resolution is by reasoning and team discussion in good faith.
|
|
- 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.
|
|
- 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:
|
|
1. discuss the issue with the TA.
|
|
2. communicate with the CSE1105 teaching team e.g. by form of email.
|
|
|