cse110-sp25-group29

Soul source of truth for CSE110

About the Team

Home Page

Quick View of Home Page

Quick Links

See the Table of Contents at the top right corner for easier navigation.

• Style Guide
• JSDocs
• Codacy Coverage Reports
• Team Charter
• Project Board

Directory Structure

.github/ISSUE_TEMPLATE
admin/
├── branding/
├── cipipeline
├── meetings/
│   ├── img/
│   ├── sprint-0/
│   ├── sprint-1/
│   ├── sprint-2/
│   ├── sprint-3/
│   └── sprint-4/
├── misc/
├── tests/
├── videos/
└── warmup/
coverage/
└── lcov-report/
docs/
├── fonts/
├── scripts/
└── styles/
source/
└── assets/
    ├── icons/
    ├── images/
    ├── scripts/
    └── styles/
specs/
├── adrs/
├── branding/
├── brainstorm/
├── flows/
├── pitch/
└── wireframes/

admin

Contains most of the documentation related to the team.

Subdirectory	Contents
branding	Boom Boom Powell team branding materials
meetings	All meeting notes and materials
meetings/img	Images for team meeting notes
meetings/sprint-0	Meeting notes for sprint 0
meetings/sprint-1	Meeting notes for sprint 1
meetings/sprint-2	Meeting notes for sprint 2
meetings/sprint-3	Meeting notes for sprint 3
meetings/sprint-4	Meeting notes for sprint 4
misc	Team charter and member acknowledgements
tests	Tests for the editor and home page of the site
videos	Videos made for the team
warmup	Warmup exercise document

• statusvideo1.mp4 has been uploaded to /admin/videos/statusvideo1.mp4. Also it’s on YouTube.
• YouTube: Final Video - Private
• YouTube: Final Video - Public

coverage

Contains the code coverage results from our tests

Subdirectory	Contents
lcov-report	Code coverage report generated by Jest

docs

Subdirectory	Contents
fonts	Fonts used for JSDocs
scripts	Scripts used for JSDocs
styles	Styles used for JSDocs

source

Contains the source code of the project. The top level holds the HTML files

Subdirectory	Contents
assets	All the peripherals to the HTML
assets/icons	Image files for the user interface
assets/images	Non-icon images
assets/scripts	JavaScript files
assets/styles	CSS files

specs

Contains project documentation.

Subdirectory	Contents
adrs	Architectural Decision Records
brainstorm	Materials from initial brainstorm sessions
branding	Project-related branding materials
flows	UX flow charts
pitch	Materials for the initial product pitch
wireframes	High-fidelity UI designs for implementation

Roles

UI/UX

Create wireframes, architecture diagrams, user interface prototype designs, branding, and assets.

• Sarah Balatbat
• Aarav Vidhawan

Figma Workspace (Request access as needed)

HOME PAGE

Implement the landing home page and its functionalities including creating a new card and showing existing cards.

• Wanting Li
• Xiaogeng Xu

EDITOR PAGE

Implement the editor page and its functionalities including creating a card from a template, creating a custom card with premade elements, and saving a card.

• Carl Ingelsson
• Jeffrey Yang
• Joseph Kim
• Kian Maher

DEVOPS

Create testing units and automation for quality assurance and conduct check-off reviews on pull requests.

• Vincent Gao
• Brandon Khor
• Arnav Talreja

Definition of Done

• Pass HTML and CSS validators
• Pass end-to-end automation
• Follow the style guides
• Reviewed by group
• Checked off by DevOps
• Specified behaviors are met (expand on this list per issue)

Setup Guide

• Setup Guide

GitHub Usage

Issues

When creating a new issue, make sure to adhere to the following:

• Check the issues for duplicates. Ensure we don’t have duplicate issues by checking if someone has added them or something similar to them already.
• Use the given templates!
  • Documentation [DOCS]: Create or modify documentation.
  • Feature [FEAT]: Feature request or non-bug modifications/suggestions to source code.
  • Bug [BUG]: Report a non-intended behavior that needs attention.
• Add the issue to the project board. This can be updated on the sidebar of a pre-existing issue as well, along with a bulk update by selecting multiple issues at once and adding them to the project board.
• Specify priority, size, and iteration. These are all applicable only to issues on the project, so this hinges on adherence to the previous requirement. Iterations are based on the weeks we are actively working on this project. Read more on priority and size below.
• Add appropriate labels! The descriptions of each label can be seen in the labels page.
• Add the assignees. If it is already known which people will be working on the issue, add them! If not, make sure to update them once they’ve been decided.
• Be mindful of issue relationships. Some issues are relevant to other issues, whether they are the “parent” of other issues, or they already have a “parent” issue. Connecting relevant issues helps us be aware of related problems that may affect each other.

Priority

• P3: High priority - Most urgent issues or must-haves by the end of the quarter.
• P2: Moderate - Features coming up next in development, or documentation like ADRs, standup notes, meeting notes, etc.
• P1: Low - Npt urgent, or nice-to-haves by the end of the quarter.

Size

Each sub-team has sizing criteria specific to their focus area.

Size	DevOps	Editor Page	Home Page	UI/UX
XS	<1hr	<1 hr	<1 hr	minor design changes*
S	1-2 hrs	1-2 hrs	1-2 hrs	new branding material & iterations
M	2-4 hrs	2-4 hrs	2-4 hrs	ADRs, team notes, flowcharts
L	4-6 hrs	4-6 hrs	4-6 hrs	major design changes**
XL	>6 hrs	>6 hrs	>6 hrs	new high fidelity designs

* Examples of minor design changes: tweaking icons, rearranging elements, changing colors

** Examples of major design changes: new variants & iterations over existing high fidelity designs

Pull Requests & Merging

When opening a new issue, it is good practice to create a new branch dedicated for that issue. This way, we can take advantage of pull requests to minimize conflicts in development.

When committing to these branches, make sure to reference the issue you are working on using the issue number. GitHub uses several keywords that can be used for closing issues, but it is also good to simply mention the issue number so that the commit can be included in that issue’s history. See example below.

When you’re done with your addition, commit to your branch, then create a pull request. This lets the team review your addition before approving the merge, minimizing conflicts and potentially buggy or unstyle code.

Stand-Up Meetings & Procedures

As established in the team charter, each team is responsible for their exact schedules, but the rough schedule is as follows:

Tuesday:    Sub-Team Sprint Planning & Stand-Up Meeting
Thursday:   Sub-Team Stand-Up Meeting
Saturday:   Full-Team Sprint Review & Sprint Plan

When sending your stand-up check ins, please include:

• Priorities: What are the curent goals you are working on
• Progress: What you have done since the last stand-up
• Problems: What is blocking your progress