Meeting Agendas - COS420-F25/F26-TeamB GitHub Wiki

Meeting Agendas:

Here are Team BlackBox's meeting agendas. Some information is redacted for privacy reasons.

Upcoming [Sprint Planning] Meeting Agenda 9/18/26

Please make sure to at least briefly review the Group's Initial Assignment: "Design Your Team" [link redacted] - if you haven't already - prior to the meeting. We'll be reviewing it and starting to do it / fill it out.

  • Briefly review roles' requirements [link redacted] (double check that you're 100% for the role you initially chose).
  • Review what is needed for the upcoming and standard meetings [link redacted] going forward.
  • Meet with the professor.

Problem Statements

Start of the "two problem statement [drafts] for your problem area" [link redacted].

  • Small problems that can be built with web stds. that we do want to solve.
  • Min. 2 Problem Statements (examples [link redacted]).

Needed to be done by the 21st:

  • GitHub Setup (Team Repo) within the class COS420 Fall 25 organization, named TeamB).
  • Team name that should begin with your team letter.
  • ReadMe (incl. chosen names, roles, and mission statement).
  • GitHub Wiki pages on meetings and communications policy.

Currently Have:

  • Team Org [link redacted].
  • Availability coordinated (other than for asynchronous deadlines/updates (see "Things needed..." below)).
  • Starting problem theme: Supporting learning critical and ethical use of Generative AI in education (or more generally).
  • Video chat platform with general communication processes established (see "Things needed..." below).

Things needed eventually to be figured out:

  • Since we do not have much cross over times aligned for the additional "mini" meetings (scrum stand-ups / status updates), we'll need to come up with deadlines for digitally reporting/updating.
  • Define written official Communication Policies [link redacted] (once we have our Wiki and [redacted] access - I'll follow up with the professor again on this).
  • On our Wiki (TBD), a listed schedule for every team meeting with scheduled times on a document.

Upcoming [Retrospective] Meeting Agenda 9/20/26

Meeting Change Needs:

  • Was everyone able to review the upcoming meeting's agenda? Are they getting out in time?

Meeting Recording Assignee's:

  • Ensure transcription is working on Zoom, OpenWhispr as backup. => Assign someone to manage backup.
  • Assign a note-taker (e.g. PM &/or Co-PM or other).
  • Assign video recorder (if we are having one).

General:

  • Finalize Team Name (if not already done) => Update on GitHub & with the professor.
  • Ensure everyone has accepted their GH Repo invites.
  • Need [redacted]'s GH username to add to the ReadMe.

Scheduling:

Change in start of the week meeting:

  • Spread out work (sprint planning and retrospective meetings are currently too close with Friday being the “start of the week” meeting).
  • Sundays will be changing to our start of the week meeting (beginning in the next week or two).

Availability Update:

Need everyone to update their availability [link redacted] with more give, if possible.

  • Need a synchronous (online in-person) meeting on Mondays (~15-30m) as a "Sprint Review" post "first meeting of the week" (Sundays). "Reserve" (in case) slots.
  • Sun 11am-12pm has some time available, but we'll need more time throughout the week.

Scheduled Deadlines:

  • Agree on scrum stand-ups / status updates asynchronous ”meetings” deadlines.
  • Go over expectations.
  • Review Communication Policies expectations.

Task Management:

  • Review task management tool(s) & expectations.
  • Need for redundancy (may need to be pushed out to next meeting).

Finalizing Deliverables for "Design Your Team" assignment"):

  • Confirm Team GitHub Organization - see example.
  • Review GitHub: ReadMe, wiki pages, etc.
  • Final review of final Problem Statements and choose the best two to submit.
  • Come up with a Mission Statement (based on finalized Problem Statements).

Upcoming [Sprint Planning] Meeting Agenda 9/25/26

Schedule Updates:

  • This meeting is considered a Sprint Planning meeting as normal until D1. (Oct 4th will most likely be our first Sunday Sprint Planning meeting, for D1.)
  • Need to meet Sunday (Sept. 27th).
  • Saturday Scrum status update (practice).
  • Deliverable 0 deadline moved from Monday (28th) to Wednesday (30th).

Documentation:

GitHub Documentation Guideline:

  • Uploading team deliverable docs to GH (see example): When uploading docs to the GH, wipe any PII (i.e. personal names) in accordance with what is displayed on the ReadMe, any internal links (i.e. Google docs), and any ref to CollaborAITE.

Task Management Guidelines (task / issue creation, task deletion, etc.):

Added to Tasks / Issues Ownership (See "Training Refs" tab on the "Team General Info doc" [link redacted] for imagery of the following):

  • Check mark any checklists (task example), if applicable.
  • Comment with ANY progress, as appropriate.
  • Comment on tasks / issues before closure.
  • Update F26 Kanban Project Board as progress is made (see "Training Refs" tab on the "Team General Info doc" [link redacted] for imagery).
  • Add “Priority” to tasks?
  • Review what the “Documentation” label is for.

Policies:

  • Policies have been archived on the "Team General Info Google doc" [link redacted].
  • Amendment to the Communications Policy: “Members should have the Discord app installed on their mobile devices with notifications…”.
  • Amendment to the Task Management Policy: “Inform team in the Discord group chat when QC review is needed.”

Deliverables:

Review "Problem Statement" doc [link redacted] for feedback, including the Project Rubric Grading feedback doc.

ALL feedback given must be addressed.

  • Update your Prob Statement based on the feedback asap per the rubric [link redacted].
  • Problem Statement (PS) tasks were broken up into three individual tasks per PS (see “Design Your Team” milestone for overview of tasks).
  • Submitting DM to the professor & final submission of PS feedback were broken into their own tasks.
  • Re-review the D0 instructions & rubric: "Wait until receiving final feedback on the PS’ before moving on with the Project Description" (need clarification from the professor, see Instructions & Rubric doc for D0 [link redacted]).
  • We’ll be creating the D0 final problem statement based on all the current problem statements.
  • Go over how some tasks are broken up (e.g., Prior Statement X is needed in order for the Task Flow Diagram X to be made).

Next Steps:

  • Submit Problem Statement revisions (see parent task).
  • Decide on an app & product description Project Description [link redacted], and assign tasks.
  • Assign Co-PM as D0 submitter.

Upcoming [Design] Meeting Agenda 9/26/26

  • Check with the professor for the following: (1) If we’re designing an entirely new app or based off of something previously existing, and (2) whether the Prior Solutions singular paragraphs are a half-page each or if it's each Prior Solution section that is a half-page each total.
  • Review past team app design examples [link redacted].
  • Design an app based on the new Problem Statement.
  • Create a name for the app & a description.

Next Steps:

  • Finish up the app description for the team to review.
  • Start on Prior Solutions & User Stories.

Upcoming [Design] Meeting Agenda 9/27/26

  • Review revised combined PS.
  • Obtain dev feedback on the design proposal to solidify it before presenting it to the group.

Upcoming [Retrospective] Meeting Agenda 9/27/26

  • Present app design.
  • Review work completed thus far.

Next Steps:

  • Assign tasks for reviewing other team members’ tasks where it could be revised or added to.

Upcoming [Design] Meeting Agenda 9/29/26

  • Go over task flow diagram creation.
  • Review design description & prior solutions, if time and completion allows.
  • Obtain team members’ internal communication platform usernames to invite to team channels.
  • Go over any additional information on the WeFlect & internal communication platform and their agentic information.

Upcoming [(true) Retrospective] Meeting Agenda 10/2/26

Go over what was how the last sprint went:

  • How did team members feel about it? Any improvements, suggestions, confusion, etc.? Anything that went well?
  • What was your experience if this was new?
  • Praise, achievements, learning something new.

Reminders:

  • Make sure to be reading the announcement / update posts.
  • Make sure to not just comment on a person’s ticket that you’re doing QC (review) for, but to also let them know in the group chat with a ping. Sometimes members may not see it sooner than a courtesy message could do.
  • When a deadline is within 48 hours, it is crucial to be more available and to look out for last minute changes within 24 hours the closer we get to turn-in – with respect to typical sleeping hours (after midnight). (Hopefully we can avoid this going forward by getting work done earlier, see below).
  • Try to get more of equal footing in task workload this time around. If you say you are going to be able to work on something at a certain time/between a certain time and that changes, inform the team.
  • These are not to call anyone an individual out. These are observations to look out for going forward for working as a team.

Review the Basic task management & QC doc:

  • Go over how QC is supposed to operate compared to making review tickets as before. Team members will start being pinged on tasks to review rather than tickets made for QC-ing. QC-ers will be tasked during the Sprint Meeting.
  • Frame of Mind going forward: Getting tasks done and “out of your ballcourt”. (Don’t have others waiting on you as much as possible.) > Rather than T-72hrs. minimum for completing tasks others are dependent on, opt for T-96hrs. (4 days) prior to deliverable deadline.
  • Commenting on tasks when ANY work is done (i.e. sentence or bullet point(s) what you did) & making sure the progress on the Kanban board reflects its progress.
  • When ready for QC > move the task from the D1 QC milestone to the DC milestone (where it’ll remain).
  • Show Roadmap & due dates reflect when tasks should be ready to be QC’d.
  • Importance of showing up to the Sprint Planning meetings.

Reason for Sprint Planning day change:

  • Allows for a break between sprints.
  • Puts a good space/decent break between major meetings.
  • Work can get done over the week rather than cramming over the weekend.

Policy Change: "Everyone needs to download the GitHub app on their phones".

  • In order to be more on top of your task management.
  • Team members will start being pinged on tasks to review rather than tickets made for QC-ing.
  • Help for being ahead of the game while moving over to the int. comm. platform.
  • Survey form should be given out tomorrow by the professor for display names then share the file on Brightspace.

Preparation of Sprint Planning Meeting:

  • Review the D1 Instructions & Rubric (see on Brightspace).
  • Request for the team's designer to find out further information on what we had questions about from D0’s design. See following ticket.
  • Request that the dev. lead review specifically the Product Backlog part of D1 instructions & rubric doc (some tasks have been created based on this). Take on managing the Product Backlog & take up as lead when it comes to dev tasks (e.g., overseeing the quality & formatting of the SRS).
  • Exchanging of int. comm. platform usernames.

Upcoming [(true) Sprint Planning] Meeting Agenda 10/4/26

  • Sundays the Sprint Planning Meetings going forward.

Policies:

  • Policy Change: Start needing a “thumbs up” reaction on “@everyone” pings/announcements to let the team know it's been seen.
  • Policy Change: Scrum status update participation will be added to Meeting Notes & Updates.
  • Dev. Policy Reminder: Merges and PRs need two members to QC & gen. AI code must be noted as such.
  • Additionally, when using AI, fill out the A1-use Reporting Form (from the Syllabus).

Task Management:

  • Leaving a comment on each task worked “each day work has been done” is a good rule-of-thumb for managing/thinking of your progress update comments.
  • Be careful when adding the comment “Fixed #X” (the issue no.) on commit messages before the task has been QC’d, it will close the task.

Review and approve of QC policy (& guidelines).

  • T-96hrs. prior to the deliverable’s due date for D1 is Oct. 10th which is the latest a task should be finished, especially if others are dependent on its completion.
  • Some due dates are sooner. See the “due date” on each task (i.e. Oct 6th for creating tasks) (see step #12 under Creating Tasks / Issues).
  • T-48hrs. Prior to the deliverable’s due date is the overall final D1 QC (i.e. Final review of SRS, Export backlog).

Review deliverables and needs for D1 (see D1 Instructions & Rubric doc):

  • D0 feedback will be broken into tasks for both the Project Description and User Story docs once feedback has been given to the appropriate members to address, depending on what needs fixed.
  • Double check your assigned tasks checklist (in the task's description) against the D1 Instruction Rubric. (You can edit it).
  • Contributions to the GitHub should be consistent and all students contribute, though factor in leads (need to consider the missing dev).
  • Need 15-30 tasks for this deliverable plus any revisions for the previous Deliverable. Each task should be small.

Assign appropriate tasks:

GitHub Archival:

Lead Dev take charge of the Product Backlog:

  • Create the backlog task items & manage User Stories (PM to QC); & Export the Product backlog for assignment submission (at the end of the deliverable?) (Co-PM to QC).
  • Have Dev Leads choose which User Stories to be addressed during this sprint.
  • Break up which of the devs are handling which User Story tasks for D1 (part of the software tasks?).

SRS Breakdown:

Software Tasks Breakdown:

D1 Overall Submission Review:

Assign QC “buddies” for relative “profession”:

  • PM : PM - for PM-related tasks.
  • Dev/PM : Dev Lead(s) - for dev leadership type tasks (i.e. managing Product Backlog).
  • Designer (& Co-Lead Dev) : Designer - for designer-related tasks (i.e. UI low-fidelity mockups/wireframes QC'd by Co-Deisgner/PM for overall design & functionality while Co-Dev Lead QC’s for representation of the requirements).
  • Dev : Dev - for dev-related tasks (i.e. extra QC's on the ReadMe build instructions update).

Upcoming [Sprint Task Management] Meeting Agenda 10/9/26

Sprint Planning:

Ask about changing Sprint Planning day. See three options below:

  1. Temporarily move to Friday (16th) to get a headstart on D2 (due Mon 26th) since we’d already have a break of 2-4 days between D1 & D2.
  2. Keep to Sunday (18th) with a longer break.
  3. Permanently switch to Fridays for starting deliverables.
  • Would be the day right after the last day of class for jumping on energy.
  • No break over that initial weekend start on deliverables, but a longer break during the week between deliverables.
  • Deliverables are due on Mondays, typically.

Sprint Review:

  • Sprint Review [Retrospective] meeting Sunday (11th).
  • Team Members are free to add to the Sprint Review Agenda (below) for discussion during the Sprint Review meeting (Sunday).

Deadlines:

One day until the deadline (for things to be done for QC).

  • We want to get all QC done by Sunday in time for the Sprint Review (occurs at end of sprint) & for Fall break.
  • Go over anything that is remaining.

Scrum status updates:

  • Post on Saturday (10th) reminder to the "teamB-scrum-update" channel on CollaborAITE.
  • No scrum Tuesday (13th) if everything is complete Sunday (goal for D1 submission).
  • No scrum Saturday (17th) if everything is complete Sunday (goal for D1 submission).

Upcoming [Sprint Review] Meeting Agenda 10/11/26

Reminders:

  • Leave a :thumbs-up: or similar reaction to an announcement or pinged on something important so the team knows it’s been acknowledged.
  • Remove the “hold” task when beginning work on a task. Sprint Review doc/meeting:
  • Review and over the [Sprint Review doc] and fill in as a team.
  • Add to this agenda (on the doc itself) if you have anything more you’d like to discuss prior to the upcoming meeting.
  • Will be reviewing both D1 & D0 revisions. Deliverable(s):
  • Last day for QC-ing, including final lead deliverable review prep for submission.
  • Export Sprint & Product Backlogs, and GitHub Documentation Archivals.
  • Submit assignment?

Upcoming [Sprint Planning] Meeting Agenda 10/16/26

Schedule Updates &/or Proposed Changes:

  • Friday (16th) is the temporary/test run for having Sprint Planning on Fridays.
  • Sunday (18th) will also be going over individually completed A2 as a team to plan the use case work.
  • Typical QC deadline for D2: Thursday (22nd).
  • Sunday (25th) Sprint Retrospective & final submission.
  • Move Tuesday’s Scrum status updates back to Wednesdays (deadlines have changed back to Mondays).
  • Proposed to condense Scrums for each two-week sprint first Sat Scrum -> first Sun meeting & 2nd Sat Scrum -> 2nd Fri meeting (only if we have the additional meeting(s)):
  1. Saturday’s Scrum status update(s) held during Sunday’s (18th) meeting.
  2. Move second Saturday’s (24th) Scrum status update(s) to Friday’s meeting (23rd).

Plans made for this sprint from the Sprint Review:

  • Have tasks broken up further for each task to be assigned with QC reviewers assigned at the Sprint Planning meeting (have fewer “tasks to create tasks” tickets), when possible -> Unable to fulfill this completely, but PM will manage "tasks to create tasks" tickets for ease.
  • It was agreed that we begin to leverage weights for tasks such as, Priority (i.e. Urgent, High, etc.), Story Points, etc. -> Determine these parameters.
  • Go over how to “Resolve issues with scheduling conflicts and communication expectations” (propose solutions or loosen up/remove policies).
  • Go over the Sprint Review changes to be achieved during this sprint (from the table). Tickets have been assigned to those who proposed changes. Other Items:
  • Go over the Sprint Review changes to be achieved during this sprint (from the table).
  • Return to the additional learning by the team LLM research ticket and the WeFlect fork. Policy changes:
  • QC tab on the Project Board changed from “Quality checking” to “QC”
  • Dev QC sub field - has a Dev QC tab on the Project Board
  • Scrum report amendments
  • Pinging channels - do we want a specific QC request/approval channel?
  • Quick ref channel (i.e. reference images)?
  • QC tasks + commenting on assignee’s task(s) or keep to the current method of keeping tasks & their OC consolidated to the QC ticket?
  • Any other policies the team wants removed/changed? Reminders:
  • To be reading the comments left on tickets for information, direction, instructions, suggestions, etc.
  • Update your progress and comment on tasks to reflect progress made on tasks.
  • Double up on notifying team members via ping in a comment on GH tickets & ping on CollaborAITE in an appropriate team channel.

D2 Tasks:

  • D1 revs - awaiting feedback. Rev tasks will be created & assigned to the applicable team members as before.
  • Have Co-PM QC deliverable item tasks against rubric?
  • PM - handle Product backlog, Sprint backlogs, & Archivals for ease - prepare & hand out docs to members who need a commit history.
  • Dev Lead manages the Product backlog as seen fit, where applicable.

SRS:

  • Also waiting for feedback to address revs.
  • PM - App Description transfer to the SRS doc? -> Co-PM QC?
  • Looks like we have enough FRs or do we need more?
  • Dev - Need 3 more NFRs -> Co-Dev Lead QC
  • Designer - choose different/more requirements to make hi-fi UI of (“Log in” is not applicable) -> Dev & PM QC

UCD & Descriptions:

  • Will go over during Sunday’s (18th) meeting - Dev Lead to help lead, if able.
  • Combine UC diagrams from A2 as a team -> Designer to complete final UCDs.
  • Combine UC descriptions from A2 as a team -> Dev Lead will assign those to the remaining UC description tasks.
  • Will need consistency between all UC descriptions, one person to do a final QC (after initial QCs)?

Software Architecture (led by dev(s)):

  • Choose architecture design type.
  • Assign team member(s) to complete UML package diagram.

Software Tasks:

  • Dev - update build instructions on ReadMe? -> Dev Lead QC?
  • Start implementation of basic UI & functionality (i.e. sign-up).
  • Build env. & dependencies need updated?
  • Return to the additional learning by the team LLM research ticket and the WeFlect fork?

Submission:

  • Co-PM - submit?
  • Reuse submission link thread.
  • Submitting after Sprint Review - goal.
  • Have PMs & Dev Lead(s) do final look over prior to submission?

Upcoming [UC & Scrum Stand-up] Meeting Agenda 10/18/26

General:

  • Go over any missing software tasks / needs.
  • Bring up the LLM research ticket and the WeFlect fork.
  • Dev Lead would handle what is needed once known.
  • Determine if we are having the Friday meeting (23rd) & merging it with the Saturday (24th) Scrum status update day as a Scrum Stand-up Meeting.
  • Scrum grace period needed?

Reminders:

  • Typical QC deadline for D2: Thursday (22nd).
  • Sign up & verify student accounts for Figma teams! The deadline is 10/19 so the designer can close out their ticket.

UCD & Descriptions:

  • Dev Lead to help lead, if able, otherwise Co-Dev Lead or Co-PM will step in.
  • Combine UC diagrams from A2 as a team -> Designer to complete final UCDs.
  • Combine UC descriptions from A2 as a team -> Dev Lead will assign those to the remaining UC description tasks.
  • Will need consistency between all UC descriptions, one person to do a final QC (after initial QCs)?
  • Discuss deadlines for the final UC diagram prior to the final UC descriptions.