Skip to main content
Version: Sprint 4

Project Methodology

Our team follows an Agile methodology, specifically adopting practices from Scrum (Schwaber & Sutherland, 2020), adapted to a lightweight, weekly-to-biweekly cadence to accommodate variable member availability across coursework. We chose this approach over a more rigid framework like Waterfall because our requirements have evolved iteratively as we've built out the editor, and Scrum's short feedback loops let us adjust task allocation and priorities each sync-up rather than committing to a fixed plan upfront.

1. Agile Framework & Communication​

  • Sprint Meetings: The project follows an iterative Agile methodology, utilizing regular sprint meetings to sync on progress.
  • Team Collaboration: Team communication and screen-sharing sessions (such as reviewing project briefs and extracting requirements) are hosted primarily on Discord.

2. Task & Issue Management​

  • Platform: Gitea is used as the central hub for tracking project milestones, issues, and overall repository management.
  • Categorization: Tasks are actively categorized using labels such as "Documentation" and "Work allocation" to keep the backlog organized.
  • Allocation: Specific issues (like editor styling, deployment, and documentation) are explicitly assigned to team members (e.g., Kauch, altairakami) to establish clear accountability.

3. Version Control & Git Strategy​

  • Branching Model: The team employs a structured branching strategy using prefixes to define the type of work being done, such as feature/ (e.g., feature/machine-parser), refact/ or refactor/ (e.g., refact/visual-editor), fix/, and build/.
  • Integration Flow: Work is not pushed directly to production; instead, branches are merged via Pull Requests into intermediate branches like dev or refact/project-structure before eventually being merged into main.
  • Continuous Integration: The application uses npm-based Gitea workflows for coverage and deployment. The current workflows target main pushes (and coverage also targets PRs to main); a dev push alone does not trigger them.

4. Documentation Strategy​

  • Centralized Docs: Documentation is treated as a first-class citizen in the development roadmap, tracked via dedicated Gitea issues.
  • Tooling: The team is utilizing Docusaurus to build and maintain the project's formal documentation site.
  • Scope: Documentation deliverables include the project methodology, Git methodology, tech stack details, installation instructions, and architectural diagrams.

Evidence of Use​

Sprint 4 Meetings​

Figure 1: Sprint 4 in-person team meeting Figure 1: Sprint 4 in-person team meeting.

Figure 2: Sprint 4 Discord team meeting Figure 2: Sprint 4 Discord team meeting, using the supplied call screenshot.

Figure 3: Sprint 4 in-person working session Figure 3: Sprint 4 in-person working session.

Sprint 4 Retrospective Themes​

The following additions are reflected in application dev at 01c423c and the current Sprint 4 documentation:

  1. Problem catalog and community publishing: Added a browsable problem set, an authoring form with public/private tests, and a QUEST panel alongside the editor. Learners can save separate solution documents associated with a question.
  2. Authoritative grading and progress: Added server-side grading against public and hidden cases, validation/execution limits, per-case verdicts and signed-in attempt/solved tracking. Guests can solve without recording account progress.
  3. Daily puzzle modes: Added black-box prediction/probe play and build challenges in the real editor, limited graded attempts, rollover countdown, policy-controlled reveals, shareable results and browser-identity streak/history. Local build tests do not spend graded attempts.
  4. Daily administration: Added admin-only reference-machine or catalog authoring, CHECK previews, generated observations, transition blank selection, date scheduling, calendar removal and fill-next-seven-days.
  5. Groq AI assistance: Added the AI inspector for explanations, fixes and generated DSL, with model selection, user API-key management, visible provider errors and explicit APPLY TO EDITOR. Requests include editor source and recent conversation through /api/ai/chat to Groq.
  6. Invitation acceptance and shared documents: Added pending invitations with accept/decline/cancel workflows, recent collaborator suggestions and a shared-document list. Accepting an invite grants contributor access atomically rather than treating a pending invite as permission.
  7. Persistent collaboration and synchronization reliability: Added PostgreSQL-backed Yjs update replay/compaction in the dedicated room service, a Nitro WebSocket proxy, shared compiler finalization and protection against stale shared-text updates overwriting newer visual edits. Room persistence remains separate from explicit file-version saves.
  8. Documentation and usability refinement: Added Sprint 4 versioning with prior sprint snapshots, source-grounded architecture/stack/third-party inventories, updated visual-editor guidance and six additional SVG wireframe sheets. Improved documentation sidebar scrolling, button/card feedback, language-reference ordering and the live Editor link.

These themes describe observable implementation changes only. They do not establish that a specific decision or discussion occurred in any pictured meeting.

Reference​

Schwaber, K. & Sutherland, J. (2020). The Scrum Guide. https://scrumguides.org