Guidelines & Procedures - COS420-F25/F26-TeamB GitHub Wiki

Guidelines & Procedures

Here are Team BlackBox's guidelines and procedures. Information will be updated as necessary.

Scrum Status Updates Guideline

Submit the following on Scrum status updates to the #teamb-scrum-updates channel on CollaborAITE:

  • 1-2 sentences about where you are at with what you're working on.
  • Any current obstacles and what's being done to tackle them.
  • What you plan to work on next.

Example: XX/XX/2026 Scrum Status Update

  • Currently: Reviewing notes & [issue with] task that's being held up.
  • Obstacles: Need to figure out where to start on [blank] issue. Going to look over past entries to compare.
  • What's Next: Discuss next steps on [blank] task in impromptu meeting and revise the last part of [blank] deliverable.

GitHub Documentation Guideline

Remove ALL PII before uploading assignment docs to the team's Repo "Documentation" (example):

  • Personal names (see ReadMe to use if names are needed)
  • Internal links such as Google docs, CollaborAITE, etc.

Task Management Procedures

The following are procedures on how to use the task management board, manage tasks, etc.

Creating Tasks / Issues:

  1. Go to "Issues".
  2. Add a simple descriptive title (i.e. "Problem Statement 1: Revise...", "'User Story' doc: Add 1 User Story") (see other "issues" for examples).
  3. Add a description with further details, including any non-PII links, checklist, etc., whatever might help assignee to understand.
  4. Assign to the appropriate team member, if applicable.
  5. Add the appropriate label(s) (e.g., "documentation", etc.), unless it's a task or bug (see next step).
  6. Add the appropriate "Type" (e.g., "task" for tasks, "bug" for bugs, etc.), if applicable.
  7. Add the team's Kanban Project Board "F26 TeamB" under "Projects".
  8. Add the appropriate "Milestone" (e.g., "Deliverable 0 QC") sub field.
  9. Click the "Create" button.
  10. Set the appropriate Kanban Project board column (e.g., "Todo/Sprint Backlog") on the "Projects: Status" dropdown or on the project board. (It is currently at "No status".)
  11. From the "Projects" dropdown, choose the appropriate "Deliverable / Sprint" iteration (e.g., "D1") sub field.
  12. Set the "Start Date" and "End Date (ready for QC by)" "Projects" sub fields.
  13. For items to display in the Project Backlog (e.g., User Stories), set the "User Story" to "Yes" within the "Projects" sub field.
  14. Set the "QC" sub field under "Projects" to the appropriate team member assigned to QC the task.
  15. Set the "Dev QC" sub field under "Projects" to the appropriate team member assigned to QC the task, if applicable.

Tasks / Issue Ownership:

Note: If tasks have the "hold" label on it, look to see what the hold is for and/or remove if task is ready to be worked.

  1. Check mark any checklists (task example), if applicable.
  2. Comment with any progress, as appropriate.
  3. Move tasks / issues along the F26 Kanban Project Board to each appropriate column as progress is made (e.g., "Todo/Sprint Backlog", "In Progress", "QC", "Done").

Closing Tasks / Issues:

When a task / issue is complete, perform the following:

  1. Comment on the task / issue with a link to the commit or document that resolved it, if applicable. (When you make a commit message, if you include in the commit message "Fixed #X", issue #X will be automatically closed and linked to the commit.)
  2. Click on "Close issue".
  3. Move the task / issue to the appropriate column on the team’s Kanban Project Board (e.g., “Done”).

Task Deletion:

For tasks / issues that will not be addressed or were made in mistake, do not delete them! Instead, do the following:

  1. Mark with the appropriate label (e.g., “duplicate”, “not valid”, “wontfix”).
  2. Leave a comment on the task / issue for the reason for closure. (Note: If duplicate, add the link to the ticket that was duplicated, as such "Closing as duplicate of #XX...". (See example.))
  3. Close the "issue".
  4. Move the task / issue to the appropriate column on the team’s Kanban Project Board (e.g., “Done”).

QC Policy Procedures

The following are procedures on QC task execution.

Prepping for a QC Request:

The task owner will do ALL of the following to ready their task for a QC request:

  1. Comment on their task with the describing the work completed (e.g., 1-2 sentences, bullet points) with a commit # [link, if possible] and/or the document name [no internal link] that “resolved the issue”. (This is so the QC team member knows where to find the work.)
  2. Move their task to the “Quality Checking” column on the F26 Kanban Project Board.
  3. Change the task’s milestone from “DX QC” to “DX” (see step #8 under Creating Tasks / Issues).

Requesting a QC Review:

The task owner will do both of the following when requesting a QC review:

  1. A ping on their task needing the QC, either with the progress update comment (see step above) or in a separate comment (i.e. “@X, task ready for QC") (see example).
  2. And a message in the CollaborAITE #teamB-general channel pinging the task owner (i.e. “@X, XX task ready for QC”).

Leaving QC Feedback:

QC team members will leave feedback via one of the following:

  1. Comments on the Google doc.
  2. On the pull request (PR) in a comment (for commits & merges).

Completing a QC Task:

The QC team member performing a QC on a task will do both of the following when finished with their QC:

  1. Ping the task owner on their task in a comment (i.e. “@X, feedback given”) (see example).
  2. And a message in the CollaborAITE #teamB-general channel pinging the task owner (i.e. “@X, QC complete”).