Home - WBot3000/choreward GitHub Wiki

Welcome to the Choreward Wiki!

Project Overview

In order to maintain a household, there are lots of tasks that need to get done throughout the day. However, often times, these tasks get neglected. Sometimes, people get distracted and turn their attention to something else. Other times, people intentionally put off their duties, as they can often be a pain to do. And keeping track of everything that needs to get done can be messy. Choreward sets to solve these problems by giving people an incentive to do their chores.

Choreward is a web app where families compete with each other in doing various household chores. Every week, the app will present all of the signed up families with certain household tasks. Members of each family can upload a video of them doing said task, while other families award points based on how much they liked the video. With these points, users within the family can purchase in-site trophies, profile customization, and rewards set by the head of the family.

Each family consists of a head (the person who makes the family group), and various “member accounts” who can post videos on behalf of the family. Besides setting up the family, the head is in charge of making custom rewards (as mentioned before), and initiating one on one chore competitions with other families. Instead of posting videos in response to a weekly objective, the two families compete directly with each other to see who can do the most chores within a certain time period. The two families get points from third party families, and whoever earns the most points within the timeframe wins the competition.

Roles

  • Project Lead: Walker Bove
  • Project Manager: Richard Kempinski
  • Architect: Rongda Kang
  • Full-Stack Developers: Rongda Kang, Ruchita Paithankar
  • AWS Manager: Rongda Kang
  • DevOps lead: Ruchita Paithankar
  • Test Lead: Hantao Guo
  • UX Designer: Rongda Kang, Ruchita Paithankar

Communications Plan

Working team meetings

Working meetings (for brainstorming, pair-programming, debugging, prototyping, internal reviews of each other’s work, etc.) aren't able to be scheduled for a specific date, due to the constantly changing schedules of the team members. However, tentative work meetings are on Mondays at any time between 6:30 PM and 9:00 PM.

Issues meetings

If a team member has a problem with the project at any moment (either they are confused about what they should be doing, or they need help doing it), they can email the project lead (Walker Bove) for any advice, which he will respond to within 24-48 hours. If a team member has a problem with the group, they can contact the project manager (Richard Kempinski).

Status meetings

Status meetings (for discussing progress with the Project Manager) will take place within the time period of Wednesdays from 6:30 PM to 9:00 PM.

Timeline and Milestones

Current timeline. Subject to change. As Agile is being used, we will be able to go back and forth between different development steps to accommodate project changes. However, the main focus of the weeks are listed below.

  • Week 1: Gathering Requirements and Creating User Stories
  • Week 2-3: Planning Architecture
  • Week 4-5: Planning Design
  • Week 6-10: Implementation
  • Week 11-13: Validation and Verification

Project Management:

  • We use Github's project management tools to manage our project (Issues, Projects, and this very Wiki)
  • Moreover, we use Discord as our daily communication channel
  • For the Production dev environment we use AWS as our service management tool.

Risks

  • The team has more experience with front-end development than with back-end development. Because of this, development on the back-end will be monitored more closely. Team members will dedicate a small portion of their working time to studying back-end technology.
  • The team might end up porting the site to React Native if there is enough time. We will compare our current progress to the timeline, and if we are ahead at least two weeks, we will attempt the porting process, keeping a separate branch for the web app just in case the porting doesn't work out.
  • The web app will need to store user data, some of which can be personal. Database functions should be contained in their own file, and each one should involve security measures when writing/retrieving data.
  • The web app will also need to store data of children under 13 years of age, so the application must abide by COPPA (https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-312). The team will write up ample Terms and Conditions and a privacy policy, on top of performing data securing methods relevant to the previous bullet point every time they write a new database function.

Assumptions

  • Target users have a device that can access the internet.
  • Every person within the household has their own device.
  • All members of the household are allowed to make an account.