Team Agreement

Team Four Agreement To help keep our team working together effectively, we are developing this team agreement. With this agreement we will cooperatively design the rules and procedures for the work to be completed during this course.

Team Values

• Communication
• Learning new technologies
• Simplification
• Being respectful even at times of utmost stress and negativity
• Transparency
• Ownership

Team Availability

Expected Commitment

Members are expected to commit enough time to complete their tasks to an acceptable level. This should be roughly 10 hours per week.
The expected workload for this course is 10 hours per week, 3 hours for lectures and 7 hours for others (like assignments, readings, quiz etc).
Front End when2meet
Back End when2meet
Leadership when2meet

Designated Availability

Members should work asynchronously as much as possible.
Choose a date/time everyone’s available/when2meet?
Do we want a set time where everyone needs to be available to work together/have a meeting?

Team Communication

Scheduled Meetings

It is expected that communication will continually take place asynchronously which may lead to a variation in the necessity of meetings, although we set some static meetings to act as anchors to sync all teams.
Weekly whole team meeting 15-minute progress update, and for raising whole-team related topics only. Time and date TBA.

• Individual teams maybe twice? But still have discord
• Individual team meetings should be flexible and change based on workload
• Leadership team should have frequent meetings to sync

Meeting Expectations

• All are to attend their respective meetings or give notice if you can’t make it.
• Keep things on topic, keep additional things for the end of meetings or in a casual discord voice.
• If daily meetings, then X times a week? And how long will they last?
• Whole team meeting should not take too long. (30 mins - 45 mins to get everything sorted?).
• Have specific things to discuss/cover every meeting otherwise they will end up going on way too long but nobody will want to be the first to say can we finish.

Meeting Process

• Via agenda, all points to be discussed need to be written down prior to meeting.
• Notes should be written on agenda live.
• Action points to be recorded for team to do before next meeting.
• Subteam meetings to subteam leader’s discretion.

Missed Meetings

• Recordings to be uploaded to the shared drive for absentees.
• Meeting minutes are available in Github Wiki.
• Have a short summary of what was discussed in the meeting.

Communication Channels

• Discord for everything except meetings.
• Zoom meetings for larger team meetings.
• Subteam meetings to subteam leader’s discretion.
• Official documentation on Github Wiki.
• Discord Threads.
• Ideally, responses are within a day.

Working Together

Deadlines

• At least one day before the canvas ddl.
• Status of the project - i.e. do we want it deployed and hosted somewhere.
• Finalise features a week before, last week for edits and bug fixing only.

Review Time

• Code owners system + buddy system.
• How long should be allowed for peer-review pull requests? 24 hours, max 48 hours.
• Make a draft PR as soon as you start working.

Work Division & Distribution.

• Recognising the issues (features) together.
• Code or documentation contributions should be associated with an open issue (should create a new one there is not).
• Issue comments - for discussing the feature, PR comments - comments about code quality.
• Frontend
  • The frontend members review the code of frontend
• Backend
  • Docs/testing/development/devops and tooling/deployment and prodeng

Definition of Done

• To include:
  • Have 2-3 other members of the team to go over assure task is done sufficiently.
  • Reviewed by at least 2.
  • Tests.

Quality Expectations

• Should be fully tested (ut, it, st) before pr (Testing team required?).
• PR checklist followed.

Delivering Status Updates

Project Status

• Project will be tracked on github projects.
• Team leaders will have sync meetings which can be reported in weekly meetings.
• Could do something like scrum like daily updates in a “stand up” channel kinda thing.

Concerns

• Talk with team leaders or other team members, if that doesn’t work, raise with leadership.
• Comments on github PRs regarding issues - maybe tag relevant members.
• Update others on communication channels about concern if needed.

Delay Transparency

• Subteam leaders to communicate to every member of the team during their meetings, to discuss delays and timelines.
• If the task is completed, ensure to coordinate with others such as team leader effectively.

Delivering Feedback

Providing Feedback

• Done in a friendly and constructive manner via code reviews, if further feedback or clarification is required then this is carried out in a friendly manner, understanding that everyone has as varying levels of experience with different technologies.
• Will have an anonymous feedback channel TBA (through Discord).

Handling Problems

Problems can be handled member to member via continued discussion from providing feedback. If contention of design direction is not resolved the parties can meet with the appropriate team leader and discuss the problem with them, during which team lead gives final decision.

Appropriate Communication Channels

Github code reviews or comments as primary source of feedback. Discord should be discouraged for feedback due to transitory/ephemeral nature of communication

Agreement Maintenance

Consequences of Breach

• Bring it up with leadership team first (or to other leaders if the person in question is a member of leadership)
• If not resolved then the issue will be raised with course staff

Signatures

02/03/2022
Abhi Rehal, Akash, Amy Lyu, Andreas, Aryan Ronee, Brooke Knowles, Fraser McCallum, Jackson Chadfield, John Jia, Johnny Zheng, Kayla Aylward, Kelvin Shen, Luxman, Oscar Li, Owen Wang, Rahul Ahluwalia, Samuel Chen, Yujia Wu