Meeting Notes - 2022-autumn-cos-420/Team-Egg Wiki

9/18 Agenda

  • Get the other two members on board with what was discussed on Friday.

  • Slogan: “Class is hard, don’t make it harder”, can we make that look better?

  • Objections to Team Egg?

  • Readiness Check to stress test our readiness timer.

  • Discuss and fill the problem document, proposed project is a “Rate my Class” idea.

Everyone present except Sean

A problem statement must introduce a problem, give examples of the problem, describe how others have tried to solve this problem before and why they failed, and what needs to be changed in order to actually solve the problem

Javascript back end, html css front end? Not set in stone

Making an egg pun doc in google drive for whenever an egg pun comes to mind

Owen was about to say something. He should say it

Get ready for reaction time tests this week. Will make adjustments to communication policies if it isn’t working

Potentially meet up to work on assignment 1 together

9/22 Agenda

Expected meeting time

5:00 - 5:55pm

Attendees:

  • Owen Bellow
  • Brennan Poitras
  • Troy Schotter
  • Graham Bridges

Fixing Schedule: 10min

Need to confirm new meeting times (Tuesday and Thursday) and move document to the wiki (where is that?).

Tuesday: End of class - 5pm (Scrum)

Wednesday: 7pm - 7:15pm (Scrum)

Thursday: End of class - 5:30pm (30min)

Friday: 3-4pm (Long)

Sunday: 1-1:30pm (30min)

Fixing mission statement: 5min

As the feedback stated, the paragraph isn’t needed and the slogan needs a bit of work.

Fixing problem statement based on feedback: ~30min or until done

“be more specific about what is problematic or what its consequences in the world”

“include more of the severe consequences, like losing money, or dropping out of school because they think they can’t do it when they just took on too much”

“be more specific about what information is needed”

“The problem statement is verbose and redundant”

“in the final question specify the causes that your team can address to make a better solution to the problem”

Discuss direction of project to make it more novel: 10min

See Student amp

9/23 Agenda

Expected meeting time 3 - 4pm

Attendees:

  • Owen Bellow
  • Brennan Poitras
  • Troy Schotter
  • Graham Bridges

Double check

Start time: When Greg shows up

Double check with Greg about the wiki, new problem document and how he wants us to keep the agenda/agenda notes updated on the github.

Rehash novel solution consideration

Estimated time: 5-10min

Check in with members about how to shift the direction of the project.

Project Deliverable 0

Estimated time: Until done

Link to Project Description document and Project Description Template for convenience,

In both Project Description and User Stories, several sections that we can section off parts and perform them independently.

If time is expected to run over too much, agree on delegating some work and push remaining to Sunday meeting.

Meeting Notes

Leaving application name as Rate My Course for now as a work in progress name, might come up with Umaine themed name later on

Possibly ask users how many courses they’ve taken in a field of study previously?

The problem statement needs to focus on the core reasons why a problem is occurring and how our system is fundamentally solving the issue at hand

Owen and Troy will fix the minor issues with the problem statement by Sunday

Owen, Troy, and Brennan will each focus on a prior solution to the problem we’re trying to solve

Graham will focus on User Stories for Sunday(I’ll try to get at the minimum ten done for myself)

Proj statement feedback:

This is a good start and you can submit updates within one week for a regrade as per the syllabus. There is a good underlying problem here: students are the best, freshest source of information about courses, but other students have trouble accessing that and might make better course decisions. The problem statement needs revision to reduce redundancy and instead go into more detail about what specific information is needed/useful and what is hard about getting it (e.g. students vary so someone’s knowledge/experience might not fit mine)). EG It is hard to know how much work a course will be, and it’s hard to match to peers that are like me and hear from them. What is the specific information and make a stronger, direct case on why knowing that is important and what students will do with it and what the benefits might be.

Consider reframing to have students share information with each other and with instructors/advisors, so everyone can understand courses better and take action to make them better. The consequence of needing to drop the class is weak unless it happens after the deadline. Some stronger consequences are students with jobs really needing to balance their time commitments and potentially failing classes; dealing with potential uncertainty/managing risk around when to do assignments and readings seems like another way to frame the underlying problem. 1 point for the meetings schedule and communications policies on your Github wiki, minus any deductions for not addressing everything in their corresponding sections above. -.2 missing another standup time besides Sunday Move your schedules to the Wiki, not as files in the repo 0.5 points for listing your team members' names and roles 0.5 points for your team name and a coherent mission statement Not clear which of the statements is the mission statement. “Class is hard, let's not make it harder.” This is incoherent because it’s not clear what you are doing, instead it is negatively phrased The closest to a mission statement I see is “promoting academic well-being and success among students” A mission statement like “students helping students..." might fit better 3 points (points will be deducted for problem statements that are unclear, verbose, logically flawed, or present a solution) for a clear, concise, logically sound problem statement that defines: the problem being solved ~”Not knowing things about the course” -.3 be more specific about what is problematic or what its consequences in the world -.2 include more of the severe consequences, like losing money, or dropping out of school because they think they can’t do it when they just took on too much the things that cause the problem -.3 be more specific about what information is needed and why existing solutions don't resolve the problem -.75 The problem statement is verbose and redundant e.g. “Students may find it difficult to blindly walk into an elective they don't know much about,” to blindly walk into and they don't know much about communicate the same thing. after they realize -> when cut “find themselves” “Advisors can always give out advice regarding course loads and descriptions but they can only offer their perspective from an advisor or instructor position most of the time. Students who have recently taken the course have a fresher experience.” -> Advisors know but not what fresh students know: Cut “with a lack of initial understanding”

-.2 in the final question specify the causes that your team can address to make a better solution to the problem

Be more specific of what sort of information is needed “Isn’t what they thought” doesn’t focus down to the problem.

9/25 Agenda

Expected meeting time 1-1:30pm

Attendees (will be updated if someone can't make it):

  • Owen Bellow
  • Brennan Poitras
  • Troy Schotter
  • Graham Bridges

Project Deliverable 0

Combine individual efforts (5min)

This should take care of most of the Deliverable 0, only leaving the "YourApp" step and a few user stories.

Finishing Last part (25min)

Consider splitting up and individually writing on a piece of paper how to diagram the app, then discussing features to have in the deliverable 0 version. Need to not get too caught up on being specific.

Meeting Notes

Potential name for website(if we veer away from Umaine system): Course Gauge

Group Deliverable: Design Your Team complete and Troy will submit revisions tonight

Look Group Deliverable 1: so we can discuss on Tuesday. Due October 1st

Add User stories to the user stories document or revise the user stories already on the document as you see fit. We want to get at least 15.

We will submit group deliverable 0 tuesday during meeting or sooner if we see fit

Graham will create a series of short paragraphs describing the features of the website

Owen, Troy, and Brennan will each come up with a way in which our app will be different/better than previous solutions

9/29 Agenda

Expected meeting time 4:50-5:30pm

Attendees (will be updated if someone can't make it):

  • Owen Bellow
  • Brennan Poitras
  • Troy Schotter
  • Graham Bridges

Zenhub Discussion (and how to use it) 5-10min

Project Deliverable 1 (20min)

  • Analyze what we need to do and how many documents it will take.
  • Decide if in-person meeting will be necessary, or if it would be a good idea to start to get into the habit.

Basics of webserver (any remaining time the team is willing to donate)

  • Get everyone on board with a basic webserver that we can manipulate through github
  • Decide what programming systems to use (need to double check with instructor to make sure if we're allowed to not use react).

9/29 Meeting Notes

Our Friday meeting tomorrow will be in-person in Boardman. Friday meeting will be our designated in-person/study time meeting

Pick two categories in the SRS to write by tomorrow

9/30 Agenda

Expected meeting time 3-4pm (but many members will arrive early) Meeting is in person, Boardman Lab 1st Floor

Attendees (will be updated if someone can't make it):

  • Owen Bellow
  • Brennan Poitras
  • Troy Schotter
  • Graham Bridges

Deliverable 0 Corrections: Unknown expected time

  • There doesn't seem to be much to correct

Project initial steps: 30min

  • Initial repository needs to be set up
  • Make sure everyone can properly start programming.
  • Go over the technical flow of the web app framework.

Deliverable 1: Remaining time

  • New due date is the 4th, no need to panic too much. That said, let's try to get ahead of the curve.
  • Delegate any remaining parts of SRS Document to be done by Sunday

9/30 Meeting Notes

We need to talk to Dr. Nelson about the project description differences feedback

Ask Dr. Nelson about the lack of a submission link on brightspace

Check with Dr. Nelson about comment on Solution 1: replace with Miro link

The sprint backlog should consist of all tasks, not just programming. Will include any other tasks like revisions on docs, like user stories or SRS

Everyone will run through the React tutorial(link in the discord)

Owen, Graham, and Brennan will contribute to the SRS doc for Sunday’s meeting

Troy will get the application’s server going over the weekend

10/2 Agenda

Meeting Time: 1pm Meeting is Online, Discord

Attendees (will be updated if someone can't make it):

  • Owen Bellow
  • Brennan Poitras
  • Troy Schotter
  • Graham Bridges

SRS Document ~30min

  • Fill in any gaps we have remaining
  • Update Table of Contents to be accurate

Sprint Backlog & Sprint Review ~20min

  • Decide how to categorize tasks and fill out documents.
  • Since we're adding things after we've already done several "sprint" things, need to consider a good policy of how we update the document in the future. Who updates the document? When will it be updated? Etc.

The App itself 10+ min

  • Questions regarding interaction between react and express, nodejs, etc.
  • Did Troy get the initial commit and the remote server working? (I sure hope I will)
  • Making sure everyone can clone from the repository and start programming features.

10/2 Meeting Notes

Finished SRS document

Updated Product Backlog

Made Sprint backlog 1

Meet in Boardman Hall for back end crash course tomorrow

10/5 Agenda

Meeting Time: 7pm Meeting is Online, Discord

Product and Sprint Backlog 2 (15min)

  • Just a quick discussion of what to put into each document to start.
⚠️ **GitHub.com Fallback** ⚠️