Skip to content

5) Meeting Log

Jump to bottom
jsh6269 edited this page Nov 28, 2025 · 17 revisions

[Meeting Log]

Date: 2025-11-28 [Iteration 5 Final Meeting]

Meeting Goal

  • Finalize User Acceptance Testing (UAT) plan and address TA feedback
  • Conduct a thorough error-handling and functional review of the app
  • Prepare all deliverables for the poster and final report
  • Review and finalize all documentation for submission

Objectives

  • Define and enforce code freeze checkpoints for frontend, backend, and testing
  • Ensure smooth UAT experience by validating major workflows and resolving last-minute bugs
  • Structure and populate final poster: motivation, UI features, system design, testing, and lessons learned
  • Refine and complete the Design Documentation and Requirements & Specifications

Task Breakdown

Code Freeze

  • Frontend freeze after final PR is merged and verified in-app (done)
  • Backend freeze once remaining model-related logic is applied and tested (done)
  • Test code freeze after achieving target coverage (FE: >80%, BE: >90%) (done)

Common Deliverables

  • Verify full app functionality (manual QA for regression and refactor-related issues)
  • Prepare and finalize project poster with shared visual assets
  • Review and complete Design Documentation and Requirements
  • Integrate any final UAT feedback before Dec 4 testing date

Additional Work in Progress

  • Prepare visual materials and validate multiple sample PDFs for poster and testing
  • Conduct thorough end-to-end run of our app

Notes

  • This is the last coordinated review before UAT and final delivery
Date: 2025-11-25 [Iteration 5 Checkup Meeting]

Meeting Goal

  • Prepare for UAT (User Acceptance Testing)
  • Complete all remaining code changes as early as possible
  • Finalize materials for documentation and the project poster

Objectives

  • Ensure UAT process and role assignments are defined
  • Target early code freeze to allow testing and polishing
  • Organize and deliver final documentation, visuals, and poster assets

Task Breakdown

  • Complete and refine the Design Documentation
  • Upload key figures and visualizations (e.g., diagrams) for poster use
  • Modify base question generation logic to utilize achievement standards
  • Refactor and finalize prompt logic for base/tail question generation
  • Implement logic to inject top-N inferred standards into prompts
  • Finalize code changes front & back
  • Apply remaining design pattern application
  • Add Continuous Deployment (CD) to the repository
  • Support achievement standard visualization and poster-ready layout adjustments

Status

  • Test coverage has met standards!
  • Code fixes is almost done (can be finished tomorrow (11/26))
  • One remaining design pattern

Notes

  • UAT plan preparation is due Thursday
  • All deliverables (code, visuals, documentation) should be clean and well-organized for handoff
Date: 2025-11-16 [Iteration 5 Kickoff Meeting]

Meeting Goal

  • Address unresolved feedback from the Heuristic Evaluation (HE)
  • Investigate and fix potential bugs throughout the current app flow
  • Refactor and clean up the codebase
  • Apply software design patterns (Factory Pattern, Builder Pattern)
  • Increase frontend test coverage to 80% or higher
  • Add and configure a frontend code formatter

Objectives

  • Usability Enhancements: Improve critical UX issues identified in previous HE sessions that are still pending
  • Bug Investigation & Resolution: Reproduce edge cases and frequent crashes across both teacher and student workflows and apply fixes
  • Code Refactoring: Review and clean up major modules including ViewModels, Screens, Models, and Network layers to improve readability and reduce redundancy
  • Design Pattern Integration:
    • Factory Pattern will be applied to dynamically instantiate Question types (e.g., base vs tail)
    • Builder Pattern will be considered where complex construction of objects (e.g., question generation requests) is needed
  • Frontend Testing: Strengthen unit and integration test cases, especially for assignment creation/submission flows, to raise coverage beyond 80%
  • Formatter Setup: Apply a consistent Kotlin formatter to ensure uniform code styling and improve collaboration

Next Action Items

Role Task Deadline
Frontend Apply design patterns, refactor UI logic, improve test coverage, and configure code formatter Iteration 5
Backend Review statistics API logic, remove redundant computations Iteration 5
ML Retrain the confidence model, improve tail question generation and explanation scoring Iteration 5
All Members Review and clean /ui/screens, /models/, /network/, and other key modules; document and simplify unclear logic Iteration 5

Additional Notes

  • Each developer is assigned to inspect and clean various parts of the codebase (e.g., StudentDashboardScreen, TeacherAssignmentDetailScreen, AssignmentViewModel, etc.)
  • Design feedback and code quality issues (e.g., duplicate renders, layout spacing, improper routing, etc.) will be addressed through targeted UI/UX patches
  • HE scenario and demo flows will be updated to reflect the latest improvements for usability testing
Date: 2025-11-10 [Iteration 4 Checkup Meeting — Usability Test Summary]

Meeting Goal

  • Summarize Usability Test Rounds (Round 1 & 2) results
  • Identify critical UX issues and refine UI/Workflow improvements before Iteration 4 Mid Review

# Usability Test Summary

Round 1 Observations

  • Assignment creation screen scroll feels awkward.
  • Problem scroll behavior unnatural when there are many questions.
  • Some hardcoded sections in statistics — especially in edit/delete assignment view.
  • Incomplete assignments should be hidden (questions not generated).
  • Profile screen crashes frequently.
  • Performance analytics screen crashes.
  • Users instinctively want to click “Learning Report” button (add actual functionality).
  • Tail question generation miss — need fix in assignment editing screen.
  • Need “Cancel” function while assignment inference or grading in progress.
  • In tab screens (“Class,” “Report”), back arrow should be removed.
  • “Class” tab should route directly to class management.
  • Add “listen again” function during assignment solving (review what user said).
  • During grading, overlay semi-transparent layer to indicate progress.
  • Currently, users can only see results after finishing all questions — feedback is needed after each base question.
    • If the purpose is learning, showing correct answers right away could be okay (students still need to explain reasoning in next tail question).
  • Unused functions (language toggle, notification settings, etc.) make UI look incomplete — remove or implement quickly.
  • Add validation for due date input format (require strict format with alert and asterisk).
  • Some parts of assignment creation process are confusing and long — workflow not intuitive.
    • Simplify and reduce redundant paths.
    • Consider adding an initial tutorial / onboarding screen to explain the workflow.

Round 2 Observations

  • When there are many students, student registration UI becomes unusable.
  • Improve toggle UI visibility.
  • Add “I don’t know” or “Skip” button when unsure about an answer.
  • Critical: After submitting, if the user exits the screen immediately, results cannot be viewed → causes Answer duplication error.
  • Incorrect correctness labeling — “Correct” displayed for wrong answers.
  • Login error messages displayed in English.
  • Input validation for date/email must be enforced.
  • Clarify if time selection is available in date picker (result screen shows time).
  • After assignment creation, exiting immediately often causes app crash (no error message).
  • Change student registration key from name → student ID, add validation.

# Workflow Improvements

Student Screens

  • Student Dashboard Banner — Add greeting banner like “Hello, Jiho!” to reduce click confusion (looks non-clickable).
  • Remove unnecessary sections — Delete irrelevant UI blocks. Keep “Assigned Assignments (N)” count visible.
  • Filter assignment list — Show only “assigned + ongoing/incomplete” tasks (exclude completed).
  • Remove ‘View All’ — Replace with header like “You have N assigned tasks.”
  • Redesign assignment card UI — Keep progress bar logic; follow new card layout (see screenshot reference).
  • Hide incomplete questions — Hide assignments with zero questions generated.
  • Delete PendingAssignmentsScreen (including deep links).
  • Delete AllStudentAssignmentsScreen (including deep links).
  • Add report banner — Apply banner-style header in ReportScreen.
  • Clarify toggles — Change “tail question” toggles into labeled buttons (“Show Tail Questions”).
  • Simplify header — Replace back arrows with fixed voicetutor logo in “Continue” and “Report” screens.
  • Remove back arrow and title in Report header, leave only logo.

AssignmentScreen

  • Add “Replay My Answer” function during solving.
  • Show semi-transparent overlay during grading.
  • Display correct answer after each base question.
  • Add “I don’t know” button for skipping.
  • Fix green background after finishing (looks like correct answer).
  • Fix tail question generation miss bug.

Teacher Screens

TeacherDashboardScreen

  • Redesign as landing page / main hub with visual cards:
    • Cards: “Go to Class Management”, “Go to Student Management”
    • Add top banner (brand color + greeting)
    • Add quick actions: +New Class, +New Assignment, Register Student, Recent Reports
    • Optionally add small insights: “Top 3 class averages” / “Weakest skill areas”
  • Show proper error screens for network failures.

TeacherClassesScreen

  • Apply non-clickable banner same as dashboard (greeting style).
  • Simplify header — remove back arrow/text, show only voicetutor logo.
  • Change top caption to “Manage Classes and Create Assignments.”
  • Update section title: “Class List (N classes)” instead of “Total Students/Classes.”
  • Remove “Recent Activities” section completely.
  • Improve card design when only showing “Students / Assignments.”
  • When creating new assignment, set selected class as default parameter.
  • Fix animation issue where “Select Class” label appears unexpectedly.

TeacherClassDetailScreen

  • Keep user in class tab when navigating to details (no tab switch).
  • Header text changed to “Class Management.”
  • Use student ID as key for student registration; support search by name/email/ID.
  • Move “Register Student” button to top, fix scroll overflow; add search bar.
  • Remove class average score section.
  • Add Unenroll Student function with confirmation modal.
  • Remove class message module completely.
  • Show compact assignment summary (hide text body; show “View Results / Edit Assignment”).
  • Add status filter toggle (In Progress / Not Started / Completed) with counts.
  • Change assignment click route → TeacherAssignmentDetailScreen (edit via button only).
  • Ensure routing for “View Results” and “Edit Assignment” matches dashboard behavior.
  • Filter out assignments with zero generated questions.

TeacherStudentsScreen

  • Remove “Send Message” buttons completely.
  • Remove message icons from list items.
  • Remove “Recent Activity” section.
  • Disable item click (no ripple effects).
  • Redesign list to non-interactive info style (thin dividers, small avatars).
  • Remove “Performance” and “Attendance” sections entirely.

EditAssignmentScreen

  • Remove “Assignment Type” field.
  • Replace “Public/Private” toggle with publish date-time field (yyyy-mm-dd hh:mm).
  • Enforce date-time input validation (same format).
  • Connect assignment statistics widget API (progress, score, etc.).
  • Implement update API with success/error toasts.

TeacherAssignmentResultsScreen, TeacherStudentAssignmentDetailScreen

  • Add “Time Spent” field.
  • Apply same toggle UI as student side.

CreateClassScreen

  • Header text → “Class Management.”
  • Remove arrow from “Create New Class.”
  • Replace all “Class” wording from “Lesson.”

CreateAssignmentScreen

  • Add cancel button during inference/grading.
  • Add calendar-based date/time picker for due date.
  • Show validation messages for missing input fields.
  • Add publish time setting (visible_from linked, filtering TBD).
  • Fix crash when leaving screen right after creation.
  • Show toast after question generation completes.
  • Remove message-related classes (MessageModels, MessageRepository, ClassMessageScreen).

AllStudentsScreen

  • Simplify header — remove back arrow/title, show only voicetutor logo.
  • Remove all message icons (top & list).
  • Disable student click interactions (non-tappable list).
  • Strengthen signup error handling (input, server, network).
  • Localize login error messages to Korean (invalid credentials, locked, network, etc.).
  • Add logout confirmation modal.
  • Simplify profile screen — show only assigned class / teacher info.
  • Remove password hints section.
  • Add account deletion support.
  • Fix issue where signup error message persists after navigating back to login.

Additional

  • Add onboarding / tutorial screen to explain the overall workflow for first-time users.
Date: 2025-11-03 [Iteration 4 Kickoff Meeting]

Meeting Goal

  • Finalize statistics and testing scope required for Heuristic Evaluation (HE)
  • Identify remaining deliverables for Iteration 3 and prioritize tasks for Iteration 4

Objective

  • Define the testing coverage and statistics features needed before the Heuristic Evaluation (HE)
  • Review remaining Iteration 3 items and establish priorities for Iteration 4

1. Common Guideline – ID Distinction (assignment_id vs personalassignment_id)

Our system uses two types of assignment IDs, and incorrect usage between them in screens or API calls can lead to data mismatch or 404 errors.

Type ID Used Purpose / Meaning Common Screens Example API
assignment_id Unique ID of the assignment itself Identifies assignment metadata (title, description, publish date, due date, etc.) Teacher’s full assignment list, edit screen, class-level assignment view /assignments/{assignment_id}
personalassignment_id ID mapped to each student’s personalized assignment Identifies student-specific progress, accuracy, and per-question results Student report, submission result, teacher’s per-student assignment detail /personal-assignments/{personalassignment_id}/answer/

Common Error Cases

  • Fetching student data using assignment_id instead of personalassignment_id, causing a 404.
  • Using assignment_id in student report screens, resulting in missing personalized results.

2. Iteration 3 Review

Key Completed Items

  • Most backend unit and integration tests completed
  • Frontend integration testing for assignment creation/submission flow completed
  • Updated scoring logic applied
    • Base question correct → 100 points
    • 1st tail question → 80 points
    • 2nd tail question → 60 points
    • 3rd tail question → 40 points
    • All incorrect → 0 points
  • Average score now calculated based on base questions only

Outstanding Issues & Deferred to Iteration 4

ID Description
P3 AssignmentScreen: Bug where leaving before answering tail questions marks assignment as completed. The fix (recalled_num < 4) might not have been applied server-side — needs verification.
P18 Tail Question Prompt Improvement — will experiment with diverse prompt variations during Iteration 4.
P19 Confidence Model: Threshold tuning completed; retraining planned before HE to handle short speech and filler words (“um,” “uh,” etc.).

3. Iteration 4 Key Tasks & Responsibilities

Frontend

ID Screen Main Tasks
P4 TeacherDashboardScreen Match “View Results / Edit” UI to AllAssignmentsScreen, ensure correct assignment_id use, verify filtering logic.
P5 TeacherAssignmentDetailScreen Connect APIs for submission rate, average score, and submission count; remove unnecessary sections.
P6 TeacherAssignmentResultsScreen Connect statistics (submission count, average grade), clean UI, ensure correct navigation to student detail.
P7 TeacherStudentAssignmentDetailScreen Implement per-student report (base + tail questions, correctness, average grade).
P8 EditAssignmentScreen Connect assignment statistics API, enable publish time configuration, redirect to dashboard after deletion.
P9 AllStudentsScreen Remove progress/average score columns, add class-level filtering dropdown, align message button layout.
P10–P12 TeacherClassesScreen → TeacherStudentsScreen Simplify navigation, unify design, display only student and assignment counts, retain performance analytics button.
P13 Performance Analytics (New) Show class-level average per assignment over time; for students, show “class average vs my score” and score trend chart.
P14 CreateAssignmentScreen Add publish time option, fix text color (consistent with LoginScreen), show “Generating questions…” indicator, retry logic for API.
P15 Student Continue Tab Ensure recentanswer API works and resumes from the next unanswered base question.
P16 ReportScreen Verify APIs for accuracy/progress/total problems; progress = solved_base / total_base.
P17 AssignmentDetailedResultsScreen Implement detailed results with base and tail questions, answer correctness, explanation, and grouped toggle UI (1 / 1-1 / 1-2).

Backend

  • Add new student report API → /personal-assignments/{id}/results/ (for P7)
  • Enhance assignment statistics API (for P5, P8, P16, P17)
  • Verify and improve class-level filtering (P4, P11)
  • Continue confidence model experiments and retraining (P18–P19)

Heuristic Evaluation (HE) Scope

View Included Excluded
Student View Personal assignment results screen, tail question interactions Achievement report, tail quality improvement
Teacher View Assignment creation → results flow, basic dashboard statistics Performance analytics, full report features

Focus of HE Testing:
Emphasize real-user experience — check for ID confusion, error flows, loading delays, and missing feedback.

Iteration 4 Demo & Deliverables

Demo Flow

  • Teacher: Upload PDF → Generate quiz → Set publish time → View results
  • Student: Solve quiz → Answer tail questions → View result report

5. Documentation

  • Update Requirements & Failure Cases
  • Complete Test Plan with coverage details
  • Update Design Docs (architecture & API revisions)
  • Log and archive Meeting Notes (this document included)

Next Action Items

Role Task Deadline
Frontend (FE) Implement and connect APIs for P3–P17 Nov 10
Backend (BE) Extend report/statistics APIs and experiment with confidence thresholds Nov 10
ML Prepare retraining for Confidence model, refine tail question prompts Nov 12
PM Finalize HE scenarios and assign test participants Nov 14
Date: 2025-11-01 [Iteration 3 Final Meeting]

Meeting Goal

  • Finalize statistics and testing scope required for Heuristic Evaluation (HE)
  • Identify remaining deliverables for Iteration 3 and tasks deferred to Iteration 4

Key Discussion Points & Action Items

1. Testing Status

  • Backend
    • Unit and integration tests nearly complete
    • Unit tests for pipeline-related utils will be added in Iteration 4
  • Frontend
    • Integration testing required by Sunday
    • Unit testing is in progress

2. Statistics Feature Scope

  • Student View
    • Required for HE: per-question result screen for each personal assignment
    • Tail question display: pending screen design decision
  • Teacher View
    • Minimal dashboard stats only for HE
    • Full analytics moved to Iteration 4

Major metric update

  • Replace “accuracy” with more intuitive scoring scheme:
    • 100 if correct on base question
    • 80 after 1st tail
    • 60 after 2nd tail
    • 40 after 3nd tail
    • 0 if incorrect after all attempts
  • Use average base question score as the main metric
  • Remove unnecessary stats for Iteration 3 and update screens

3. Tasks Moved to Iteration 4

  • Achievement evaluation (report) page
  • Course-related feature integration
  • Tail question quality improvement (prompt and threshold tuning)
  • Bug fixes recorded in GitHub issues

4. Remaining Focus for Iteration 3

  • Complete frontend unit testing
  • Prepare demo flows:
    • Teacher: PDF upload → quiz creation
    • Student: quiz solving → per-question result view
  • Documentation updates:
    • Requirements and failure cases
    • Test plan including coverage
    • Design docs (architecture and API updates)
    • Meeting logs
Date: 2025-10-30 [Iteration 3 Checkup Meeting]

Meeting Goal

  • Ensure core implementation is ready for Heuristic Evaluation
  • Finalize demo development scope and remaining documentation/testing tasks

Key Discussion Points & Action Items

1. Development Scope (Demo)

To be included in Iteration 3

  • Teacher View
    • PDF upload + quiz generation
    • Page to view generated quizzes (if possible)
  • Student View
    • Quiz solving screen (implemented)
    • Quiz result screen (target for Iter 3 completion)

To be deferred to Iteration 4

  • Class creation/modification, student registration
  • Achievement evaluation report page

2. Current Development Status

  • Backend
    • API implementation nearly complete
    • Test coverage 85% (meets requirement)
  • Frontend
    • Requires backend integration and additional screens
    • Tests not written yet (prioritize demo usability)
  • Research
    • Adjust threshold / retraining scheduled
    • Improving tail question quality for A-bucket
      • Prompt and example updates
      • Option: two consecutive A → show guidance and move to next base question
      • Future option: include material data

3. Testing Status

Testing Type Status
Backend Unit Test Done(85%)
Frontend Unit Test In progress
Integration Test In progress

4. API Discussion

Prioritized for Iteration 3

  • GET /feedbacks/dashboard/recent-activities/

Planned for Iteration 4

  • PUT /courses/classes/{id}/students/
    • CSV vs single registration → whichever is easier for frontend
  • /feedbacks/messages/
    • Backend already implemented; usage decision pending

Under Review

  • GET /assignments/{id}/results/
  • GET /assignments/{id}/questions/
  • GET /courses/students/{id}/assignments/

(All API-related issues are registered on GitHub)

5. Decisions & Next Steps

  • Complete core teacher-student quiz flow for HE
  • Keep research updates minimal for stability
  • Documentation and integration test updates required
  • Deployment and connection validation required
Date: 2025-10-20 [Iteration 3 Kickoff Meeting]

Meeting Goal

  • Define goals and responsibilities for Iteration 3
  • Prepare for testing phase and midterm presentation
  • Finalize API revisions and ensure readiness for Heuristic Evaluation

Key Discussion Points & Action Items

1. Testing & Evaluation

  • Unit Testing
    • Each member tests their own implemented features (Add feature: A → Test A)
    • Log coverage results and fix bugs
    • Consider swapping test ownership for better coverage
  • Integration Testing (PM)
    • Track tested user stories
    • Ensure end-to-end flow (Frontend ↔ Backend) works as expected
  • Heuristic Evaluation (11/6, Iteration 4 Week 1)
    • PM (+1 member) presents testing method to other teams
    • Other teams evaluate the app for usability issues
    • Collect and document feedback to propose improvement solutions

2. Midterm Presentation (10/28 or 10/30)

  • PPT Preparation: Doyeon
    • Focus on Innovation/Usefulness, Technical Strength, and Research overview
    • Include progress and core demo features
  • Team to finalize slides and rehearsal before deadline

3. Backend & Frontend Development

  • Core Features for Iteration 3 / Heuristic Evaluation
    • CRUD for Dashboard, Questions, Students, Classes
      • Backend: Junyoung
      • Frontend: Jiho, Junha \
      • Testing: Backend, Frontend each
    • Submit Assignment (ASR → Feature Extraction → Inference → Tail Question)
      • Backend: Junyoung
    • Push Notifications: Junha
    • Achievement Evaluation (Using GPT): Suhan
    • Report Generation: Suhan
    • API Revision & Integration: Jiho
    • EC2 Backend Deployment Setup: Suhan

4. Documentation & Deliverables

  • Requirements & Specifications
    • Add user stories, UAT, and failure cases → Doyeon
  • Design Document
    • Add testing plan section → Doyeon
  • Meeting Logs
    • Kickoff / Checkup / Final meetings → Doyeon
  • Other Deliverables
    • Wireframe, Class Diagram, ERD, and API updates before submission
    • Iteration 3 final submission: 11/2

5. Deployment & Coordination

  • Prepare EC2 environment and finalize backend setup (Suhan)
  • All members prepare demo for midterm presentation
  • Run pre-commit for all files → merge PRs before new branch creation to avoid conflicts

6. Additional Discussions

  • Assignment Creation Enhancement:
    • Add grade and subject input fields (Frontend + Backend)
    • Used for extracting curriculum-based learning objectives
  • Frontend Simplification:
    • Merge all assignment creation options into one (PDF + Grade + Subject)
  • API Documentation:
    • Keep API specs only in Notion, remove from frontend/ to avoid confusion
  • Database Design:
    • Use self-FK within questions table to represent tail/sub-question relations
    • assignment_id added to questions; personal_assignment_id can be NULL for base questions
    • Finalize naming convention: “tail question” (decision pending)

Decisions & Next Steps

  • 📍 Iteration 3 Core Goal: Complete testing, finalize features, and prepare for midterm & heuristic evaluation.
  • 📍 Architecture Focus: Backend-Frontend integration with EC2 deployment.
  • 📍 Deliverables: Working app with CRUD, quiz submission, and GPT-based evaluation ready for demonstration.
Date: 2025-10-17 [Iteration 2 Final Meeting]

Meeting Goal

  • Adjust implementation details for main logic (quiz generation & PDF handling)
  • Finalize assignments for Iteration 2 working demo preparation
  • Review postponed and cancelled tasks for Iteration 2

Key Discussion Points & Action Items

Main Logic Implementation Details

  1. Assignment Creation Update

    • When creating an assignment, the grade level and subject must be entered from the frontend and transmitted to the backend for storage.
    • These fields are required for extracting curriculum achievement standards from PDF educational materials.

  2. PDF Handling & Storage Logic

    • Define the S3-based upload and storage flow for PDF materials in detail.

  3. Question Model Behavior

    • Ensure that initial questions are generated when an assignment is first created.

Task Assignment (Iteration 2 Working Demo Preparation)

Task Description Assignee
Tail Question API Improve logic and stability Doyeon
PDF API & Main Logic API Add PDF upload API and revise main logic API; finalize frontend–backend integration Jiho
Main Logic API Implement main logic backend endpoint Suhan
DB Pre-setting Script Prepare initial database script for Iteration 2 demo Suhan

Iteration 2 Document Preparation

Task Description Assignee
Design Documentation Update Reflect revised API specifications Junyoung
Testing Plan Outline Add detailed testing plan (when / how often / who) Junyoung

Cancelled & Deferred Tasks

Task Status Reason
Visualize Total React Agent Structure Cancelled Latency issues → React Agent visualization removed
Set up Backend Program on EC2 Postponed to Iteration 3 Deployment after backend program completion
UI/UX Design Improvement Postponed to Iteration 3 Potential merge conflicts during backend/frontend integration

Decisions & Next Steps

📍 Main Logic Update: Added grade & subject fields in assignment creation, clarified PDF S3 storage process, and defined question generation timing.
📍 Working Demo Goal: Complete full backend logic integration and front–back sync by Iteration 2 demo.
📍 Documentation: Update Design Doc to reflect new implementation details.
📍 Deferred Items: EC2 deployment and UI/UX design to be addressed in Iteration 3.

Date: 2025-10-14 [Iteration 2 Checkup Meeting]

Meeting Goal

  • Refine development scope and finalize updated responsibilities for Iteration 2
  • Prepare demo deliverables for Iteration 2 presentation
  • Resolve Django ERD structure and dependency issues

Key Discussion Points & Action Items

1. Development Scope Refinement

  • Exclude objective + descriptive question generation logic from project
  • Identify need for additional analysis logic to support individualized student report generation → Full implementation postponed to Iteration 3

2. Task Assignment

Documentation Improvements – Junyoung

  • Revise documents based on Iteration 1 feedback
  • Update User Interface Requirements to handle failure cases
  • Add table of contents hyperlinks
  • Expand Design Documentation with API specification and Testing Plan outline

Iteration 2 Demo Preparation

  • Write README.md (ver.2) – Junha, Junyoung
  • Write development.md (ver.2) (Frontend) – Jiho
  • Build working demo prototype – Suhan, Doyeon
  • Record demo video – Jiho
  • Implement backend API for “follow-up quiz generation based on answers” – Suhan, Doyeon
  • Draft dummy question list (scenario-based) – Suhan

3. Django ERD Structure Improvement & Dependency Issue Resolution

Identified Issues:

  1. The Question model currently resides under the submissions app, which is semantically inconsistent.
    • Questions should exist when an assignment is created, not only when submissions occur.
  2. Restricting each assignment to a single Topic wastes backend resources and limits flexibility.

Decisions:

  • Introduce a new standalone questions app to handle question entities.

    • This avoids ambiguous dependencies between assignment and submission apps.

  • Modify Assignment–Topic relationship to many-to-many (M:N).

    • Use Django’s built-in ManyToManyField API (no intermediate table fields needed).

Question Creation Flow (Revised):

  • When an assignment and its PDF material are created, the initial questions for each student are generated and stored.
  • Follow-up questions based on student responses will be generated dynamically via AI.

Decisions & Next Steps

  • 📍 Scope Update: Excluded objective/descriptive quiz logic; added analysis logic planning for student reports (Iteration 3)
  • 📍 Architecture Update: Added independent questions app and redefined assignment–topic M:N schema
  • 📍 Deliverables: Demo-ready backend + frontend integration, revised documentation, and ERD improvements
Date: 2025-10-06 [Iteration 2 Kickoff Meeting]

Meeting Goal

  • Define goals and responsibilities for Iteration 2
  • Establish strategy for AI-driven quiz generation and evaluation, and design AI-powered architecture
  • Plan deployment strategy

Key Discussion Points & Action Items

1. Backend Development

  • Implement basic feature extraction logic – Doyeon (0.5hr)
  • Prototype training pipeline setup & performance upgrade – Doyeon (3hr)
  • Integrate ASR with acoustic & semantic features – Suhan (1.5hr)
  • Design AI prompt templates for quiz generation – Junyoung (1hr)
  • Implement quiz generation feature (LangChain + React Agent prototype) – Suhan, Doyeon (3hr)
  • Design prompt for answer evaluation & feedback questions – Junyoung (1hr)
  • Implement evaluation & feedback generation feature (React Agent) – Suhan, Doyeon (3hr)
  • Create ERD-based django model – Junha (1hr)
  • Configure URL settings & initial backend endpoints – Junha (0.5hr)
  • Collect learning objective dataset - Junha (2.5hr)

2. Frontend Development

  • Android Kotlin code implementation (basic interaction flow) – Jiho (5hr)
  • API specification draft & integration test code – Jiho (3hr)
  • Frontend class diagram drafting – Junha (2hr)
  • UI/UX design refinement (early-stage screens) – Junha (3hr)

3. Deployment

  • Initial EC2 backend setup & deployment pipeline design – Suhan (2hr)
  • Draft roadmap for iteration-based deployment – Team discussion

4. Documentation & Deliverables

  • Improvement Requirements & Specifications – Junyoung
  • Improvement Design Documentation – Junyoung
  • Meeting Logs & Iteration Records – Junyoung

Decisions & Next Steps

  • 📍 Iteration 2 Core Goal: Build the first integrated pipeline for AI-based quiz generation & evaluation.
  • 📍 Architecture: Align LangChain-based prompt system with backend (Django + React Agent).
  • 📍 Deployment Plan: Establish EC2 environment
  • 📍 Deliverables: Working backend prototype, Android integration demo, and updated documentation.
Date: 2025-09-28 [ASR & Speech Evaluation Discussion]

Meeting Goal

  • Define strategy for handling ASR evaluation and filled pause detection
  • Plan data utilization and feature extraction for presentation speech evaluation
  • Discuss potential approaches for personalization and per-speaker calibration

Key Discussion Points & Action Items

1. Dataset & Labeling Strategy

  • ASR System: Using NAVER CLOVA ASR.

    • Goal: Handle pauses and filler sounds ("음", "어", etc.) accurately and for free where possible.

  • Dataset:

    • AI Hub – Korean speech presentation dataset (~3–4 mins per sample)
    • Includes various speaker groups (middle school, high school, 20s–50s).
      • middle school + high school + 20s ~= 450 data
    • AI Hub Dataset Link

  • Annotations included:

    • Filled pauses: “음... 어... 그러니까...”
    • Mispronunciations, hesitations, prolonged expressions
    • eval_grad: letter-grade style evaluation of presentation quality

2. Approach – How We Plan to Use the Data

  • Use features extracted from acoustic modules (e.g., librosa) and transcripts (e.g., frequency of filled pauses).
  • Here, the word 'features' means acoustic measures such as slope of f0, min/max/variance of f0, silence ratio, etc.
  • Train a model to predict eval_grad (presentation quality label) from combined features.
    • possibly decision tree based algorithm (needs more experiments)
  • Since labeling needs too much effort, we need to use existing labeled dataset
  • Goal: Evaluate (estimate) overall speech quality
  • During actual service:
    • Use model output together with LLM-generated evaluations.
    • Provide feedback on whether the answer is logically correct.
    • Generate follow-up questions based on evaluation results.
    • Store those infos and use them when we make a summary report for the teacher.

3. Key Considerations

  • Accuracy:
    • ASR results should capture filled pauses (“음... 어...”) with high precision.
  • Data Requirements:
    • Must include transcript and evaluation grade.
    • Should list 1–3 potential signs of cognitive load or hesitation markers likely to influence evaluation.
  • Data Processing:
    • Download and preprocess the dataset for internal use.
      • make the format consistent!

Discussion Outcomes & Reflections

  • Uncertainty Estimation:
    • Public datasets often lack uncertainty labels.
    • We may need to label data ourselves if uncertainty estimation is required.
    • Tentatively concluded that evaluation on overall performance is enough.
  • Per-Speaker Calibration:
    • Normalizing features per speaker appears important.
    • However, applying per-speaker normalization to the dataset is often very difficult.
    • In a real service, we could collect a short sample recording for calibration — but feasibility remains uncertain.
  • Decision:
    • Calibration seems possible but may not be essential if feature extraction and labeling are sufficient.
    • We focus on overall performance as a supplementary indicator when generating further questions.

Decisions & Next Steps

  • 📍 Proceed with model training using librosa features + transcript features.
  • 📍 Explore per-speaker calibration but keep it optional at MVP stage.
  • 📍 Utilize eval_grad as the primary metric for evaluating presentation quality.
  • 📍 Design service logic to provide feedback and follow-up questions based on evaluation results.

⭐️ Conclusion:
The team agreed that focusing on filled pause detection, acoustic/verbal feature extraction, and eval_grad prediction is a feasible path forward. While per-speaker calibration might improve accuracy, it is not mandatory at this stage. The emphasis is on building a working evaluation model and integrating feedback generation into the product’s core logic.

Date: 2025-09-25 [Team Sync]

Meeting Goal

  • Define detailed tasks and deadlines for the MVP phase
  • Finalize logging, communication, and branching strategies
  • Review current prototype and assign conversion tasks
  • Share key research findings and discuss their implications

Key Discussion Points & Action Items

1. Task & Deadline Planning

  • ✅ Set deadlines for each task and ensure accountability.
  • ✅ Decide on logging format and tool stack for task management.
    • Options discussed:
      • a. Notion, Git – possible double tracking
      • b. Slack, Discord, KakaoTalk – too fragmented → need consolidation

2. Prototype Review & Next Steps

  • Current version review: Shared screen to demonstrate existing features – Junha
  • Plan to deliver .zip version to team members if needed.

Next steps:

  • ✅ Build wireframe – Junha

3. Paper Review & Insights

  • Discussed current research direction and insights.
  • Key points shared:
    • “Total duration” feature in existing research is not relevant for our project.
    • How to personalize speech habits/characteristics? (e.g., normalization by speaker)
    • During signup, consider collecting personal questions that don’t add difficulty but allow personalization.
    • Define value metrics per feature (importance and impact).
    • Most research is English-centric — plan small beta tests with students for contextual validation.
    • Which deep learning architectures (e.g., Bayesian neural networks, variational inference models, or decision tree) are most effective for uncertainty prediction in speech-based tasks.
    • How to collect Korean speech datasets for machine learnig.

4. Git Workflow & Branching Plan

  • Branch structure:

    • main → split into front/ and back/ folders → each folder contains feature-specific branches.

  • Front-end plan:

    • Create feature branches and incrementally push Kotlin-converted code.
    • Use pre-commit for code formatting and style checks.

  • Back-end plan:

    • 9/25 (Thu) – Push initial Django project version
    • 9/26 (Fri) – Pull updates and set up pre-commit hooks

Decisions & Next Steps

  • 📍 Consolidate communication and logging tools to avoid fragmentation.
  • 📍 Continue Kotlin conversion and wireframe building in parallel.
  • 📍 Review signup flow and personalization approach based on research insights.
  • 📍 Beta test the system with a small student group for qualitative feedback.
Date: 2025-09-19 [Iteration 1 Kickoff Meeting]

Meeting Goal

  • Validate the core idea at MVP level
  • Finalize initial development and research directions
  • Define goals and responsibilities for Iteration 1

Key Discussion Points & Action Items

1. Project Setup & Management

  • Branching Strategy – Junha (1.5hr)
    • Define main branches: main, dev
    • Establish naming rules for feature, bugfix, and release branches
  • GitHub Commit Bot Setup – Junha (1.5hr)
  • GitHub Issue Format Setup – Jiho (0.5hr)
  • GitHub Wiki Template Setup – Jiho (0.5hr)
    • Prepare templates for Requirements & Specifications
  • Commit Message & PR Convention – Junha
    • Examples: feat: add new feature, fix: typo

2. Research & Technology Review

  • Literature Review – Signal Processing for Acoustic Response Analysis – Suhan, Junyoung (4hr)
  • Research on AI Interviews & Follow-up Question Techniques – Doyeon (4hr)
  • Speech Processing (ARS) Technology Review – Jiho (4hr)
    • Includes Speech-to-Text capabilities
  • Speech Processing Prototype Development – Suhan, Doyeon (4hr)
  • Metric Definition – Team discussion on how to track progress and measure outcomes

3. Early Prototype Design

  • Core Flow Sketch (Figma) – Jiho (3hr)
    • Flow: “Microphone → Question → Read Answer → Follow-up Question”
  • Basic Wireframe Design – Jiho (3hr)
  • DB Architecture Design (RDS + S3) – Suhan (3hr)
    • End-to-end flow: Android ↔ Django ↔ LLM API ↔ TTS
  • ERD Design (Q&A Log Model) – Junyoung (2hr)
    • Entities: User, Question, Answer, Log

4. Code Quality & Workflow Setup

  • Linter / Formatter Setup – Junyoung (0.5hr)
  • Pre-commit Workflow Setup – Junyoung (0.5hr)

5. Documentation & Deliverables

  • Requirements & Specifications Drafting – Junha (2hr)
  • Design Documentation (Post-Iteration) – Jiho (2hr)
  • Iteration 1 Presentation Material – Junha (3.5hr)
    • Include front-end screens, Django code based on ERD
    • Demonstrate prototype results based on literature review or initial tests

Decisions & Next Steps

  • 📍 Kickoff Meeting: Scheduled for next Tuesday
  • 📍 Iteration 1 Goal: Deliver a functional MVP to validate the core idea
  • 📍 Future Iterations (2–5): Will focus on expanding functionality and improving system sophistication

Clone this wiki locally