Policies

Here are Team BlackBox's policies. Some information may be redacted for privacy reasons. Information will be updated as the team moves communication platforms and other necessary changes.

Communication Policy

• See the "Team Schedule" for scheduling times, deadlines, and meeting information (Home Wiki page.
• All members are expected to submit Scrum status updates before their scheduled deadlines on the applicable days. See Guidelines & Procedures for submission guidelines.
• Scrum status update reporting may be given a grace period of up to 24hrs. past the Scrum due date to post, for those who give notice ahead of time.
• Members should have a CollaborAITE (.) net shortcut on their mobile devices with notifications set up; all real-time & important information is communicated in the appropriate CollaborAITE team channels.
• Members shall check CollaborAITE team channels at minimum twice per day and direct messages from the PM / Co-PM at minimum once per day. During encroaching deadlines, members are expected to respond more often / quickly.
• Ping members as necessary and use "@TeamB" for important or urgent matters in the appropriate CollaborAITE team channels. Avoid unnecessary or excessive pings. Note: On CollaborAITE, DMs are treated like channels, so pinging the member being direct messaged helps with visibility.
• Members are expected to acknowledge "@TeamB" pings, such as announcements or other update by the leads and individual notice pings that request attention, with a ":thumbs up:" or similar reaction to confirm the message has been seen and read.
• When members are not directly named / pinged in the group chat for posted questions, anyone is free to respond. Those who know the answer should respond first. Questions directed at a specific member or their area of expertise / responsibility should be the one to address it.
• Members should have the GitHub app installed on their mobile devices with notifications set up for receiving/being pinged on tickets (e.g., to QC, to let someone know QC is complete).

Meeting Policies

Meeting Documentation:

• All documentation (Meeting Notes, Agendas, Updates, Scrum Participation Reporting, etc.) is archived in "Meeting Notes & Agendas Archive" on Google Docs [redacted link] within 24 hours and on the Meeting Notes & Updates Wiki page within 48 hours.
• Meeting Agendas will usually be posted the day prior to a meeting, but no less than 2 hours prior in the CollaborAITE "teamb-meeting-notes-or-updates" channel.
• Members shall review the Meeting Agenda prior to meetings and any other posts thereafter.
• After submissions for assignments, deliverables will be archived on GitHub with PII & relative information removed in accordance to GitHub Documentation Guideline.

General Expectations:

• Members are free to bring up topics as needed during meeting, however, time-consuming troubleshooting or collaboration should be left to toward the end or schedule a meet up as needed.
• Members shall take initiative in scheduling meet ups with the respective team members as needed outside of regular meetings.
• It is expected that members keep the scheduled flex times / overflow available when during encroaching deadlines.

Attendance | Schedule Changes:

• Attendance is recorded during synchronous meeting and logged in the Meeting Notes (see links above).
• Members are expected to attend regularly scheduled meetings, unless due to changes outside their control which should be communicated with the team in the CollaborAITE "teamb-availability" channel immediately.
• Absent members are expected to check CollaborAITE team channels and DMs by end of day post hold-ups. It is expected they review and address anything missed.

Task Management Policy

• Tasks will be assigned during Sprint Planning meetings. Members shall manage ownership of their tasks by updating their progress, and closing them out when complete after QC feedback and task revisions are satisfactory (see Quality Control (QC) Policy below).
• As progress is made on a task, add a simple comment stating what work was done each day (see Guidelines & Procedures). See Quality Control (QC) Policy (below) for QC needs.
• When available, members should proactively take open tasks or check with the team rather than wait for a task to be assigned.
• Members should bring any task hold-ups (i.e. issue, obstacle, frustration, confusion) to the team or an appropriate team member to help address it by end of day of hold-up.
• If tasks feel too large or the workload feels uneven, members should raise concern immediately.

Quality Control (QC) Policy:

• Tasks that need QC will be assigned to a minimum of one QC team member upon task creation, whereas merges and pull requests require a minimum of two (see Development Policy below). Secondary QC team members will typically be a lead. Note: To see which team member is assigned to QC a task, look at step #14 under Creating Tasks / Issues or the Quality checking tab on the Kanban Project Board).
• All software QC’s will be conducted by the dev leads (see Development Policy below).
• Task due dates reflect when tasks need to be ready for QC. Typical due dates are set for a minimum of T-96hrs. prior to the deliverable’s due date.
• At T-48hrs. prior to the deliverable’s due date, the appropriate leads (e.g., PM, Dev Lead) will conduct a final QC to ensure consistent and cohesive look (i.e. formatting, flow between sections) for submission.
• Any outstanding deliverable tasks past QC the T–96 hours deadline are flagged during Sprint Review.
• When a task is ready to be QC reviewed, the task owner will follow the "Prepping for a QC Request" procedure.
• Task owners will then inform their assigned QC team member via the "Requesting a QC Review" procedure.
• QC team members will review the task owners work against the task’s description for the rubric information (i.e. checklist), leaving feedback in accordance with the "Leaving QC Feedback".
• When the QC is done, the QC team member will communicate with the task owner following the via the "Completing a QC Task" procedure.
• "Requesting a QC Review" & "Completing a QC Task" procedures above will repeat until satisfaction is reached between the task owner and their QC team member before the task can be closed out (see example).
• When all feedback has been corrected by the QC team member (if minor fixes) and all revisions finalized, the task can be closed (see Closing Tasks / Issues), unless the task is assigned with a secondary QC.
• If there is a secondary QC team member (under the "Dev QC" sub field - see step #15 under Creating Tasks / Issues), the same process will apply until satisfaction is reached between the task owner and their secondary QC team member before the task can be closed out.

Development Policy

• All merges and pull requests must be reviewed by at least two developers before being completed (Copilot or any other AI does not count). Developer rank does not change the number of reviews required.
• AI generated code blocks/snippets must be noted as such for further review by the team.
• Defects must be resolved whenever a pull request with said fix/feature is merged. If the issue is not resolved within 24 hours, the issue will be escalated.