Welcome to the Team-E wiki!

On this page (Home) you can find information about our meetings and attendance and communication policies that we decided upon at our first meeting.

Weekly Meetings

Meeting Times:

We will meet weekly via Discord in the Team E voice channel on Sundays from 1-2pm for Scrum Kickoffs and task management. We also have a weekly workshop and task management meeting on Wednesdays from 7-8pm.

Meeting Documentation Information:

Meeting Agendas will be posted prior to the meetings to the 'Meeting Agendas' folder in the shared drive as well as to the GitHub.

We will also have Meeting Summaries/Notes posted to the same places a few hours after the meeting has completed. In the unlikely scenario that something prevents the summaries from being posted a few hours later, they will be posted at some point the next day.

Attendance Policy:

Attendance is taken at the meetings and put into the review/notes document for that meeting.

If there is a reason a team member is unable to attend a regularly scheduled meeting, they should communicate such with their team members in advance.

Communications Policy

Team members should respond in the discord team chat by the end of the day if not able to within a few hours. When there are encroaching deadlines, team members are expected to respond more quickly.

When messaging the team chat, members should use @everyone for reminders of time (upcoming meetings, deadlines, etc), or when the message should be viewed as soon as possible and involves everyone. When @everyone is used in a message, everyone is expected to respond unless in the case that it is a reminder not requiring response.

When a message is sent in the team chat, so long as it is not directed to a specific person, all members are permitted to respond.

Quality Checking Policy

All team members shall have their deliverable work reviewed by another team member. This quality checking process should be conducted by another team member familiar with the work (e.g. doing similar work on that part) for efficiency, and distributed across the team. This quality checking should be complete at least 24 hours before any final review of the whole deliverable done by the team (e.g. before a team deliverable review meeting). This includes reviewing code / pull requests.

If a reviewer is not assigned already, the person that did the task will assign a reviewer, by:

1. Write a comment on the task @'ing a specific person to do the review e.g. “@name for review:”
2. The comment also has either: a) a couple sentences/bullet points on what was done, or b) “see assigned comments” then add comments on the document on the relevant parts and assign the comments to the reviewer
3. Check the task description in the kanban has the rubric information and/or grading comments that were addressed, so the reviewer knows what to check. If it’s missing, the person doing the task needs to add it.
4. Move the kanban task to the “Waiting for Review” or similarly named lane lane

The reviewer will review / quality check by:

1. Open task in the kanban to view the task guidelines and open relevant examples
2. Open the work and compare to the task description and examples for quality and completeness
3. For revisions, looking at the edit history is very helpful to see what changed
4. Any questions about the reviewed work will be asked of the author in order to clarify any ambiguity or misconceptions, as comments on the kanban task or document
5. Work that does not pass quality check will either be: a) fixed by the reviewer if the work is understandable and fixes are minor, or b) moved back to the In Progress lane and a comment added with what is not done/needs to be fixed (or questions)
6. Work that passes quality checks will be advanced on the kanban; if the reviewer did work they should add a comment on the task with the rough percentage of the task they did/fixed

Be friendly to your team in writing your comments and assume they did they best they could with the knowledge they had at the time. If there is an issue with a person doing work that needs lots of revisions, figure out the root causes via discussion e.g. at the sprint retrospective (root causes might include: knowledge, not seeking clarification, not looking at the examples before doing the work, someone with better knowledge should have been assigned the task or provided mentorship, etc).