• 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

Expected meeting time

5:00 - 5:55pm

Attendees:

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

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)

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

“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”

See Student amp

Expected meeting time 3 - 4pm

Attendees:

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

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.

Estimated time: 5-10min

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

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.

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.

Expected meeting time 1-1:30pm

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

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

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

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.

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

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

• 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.

• 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).

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

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

• There doesn't seem to be much to correct

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

• 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

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

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

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

• 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.

• 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.

Finished SRS document

Updated Product Backlog

Made Sprint backlog 1

Meet in Boardman Hall for back end crash course tomorrow

Meeting Time: 7pm Meeting is Online, Discord

• Just a quick discussion of what to put into each document to start.

Meeting Time: 4:50pm Meeting is Online, Discord

• Presentation due date is looming, top priority is to handle that.

Made Sprint backlog 2 and Product backlog 2 specifically regarding presentation items

Meeting Time: 3pm Meeting is Online, Discord

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

• Brennan Poitras
• Troy Schotter
• Graham Bridges

• This shouldn't take long, but we need to decide who we're theoretically selling this app to or how it's going to be funded.

• Split into groups of two. Two people working on the synopsis and two people working on the taskflow/ui diagram.
• Aim to have presentation (the slides at least) done by this session.

• Before passing this off to Troy and Owen, need to agree on points to bring up and the general organization of the slides. Make sure we're checking off all the requirements.

Remember to not lose track of the problem statement while in development

Make the product backlog more clear on what we have completed

Product backlog should be filled with everything we’re planning to do by the end of the course

Project Proposal Presentation pushed back to Wednesday, 10/12

Owen wasn’t able to make this meeting For Sunday, Graham and Owen will work on the UI presentation slides and Troy and Brennan will work on the introductory/project slides

Need to work on how to make better use of the kanban board

Meeting Time: 5pm Meeting is Online, Discord

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

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

• How are people doing on their slides?
• Set up plan of who is in charge of getting them together and by what time to get them together by.
• Set up time to create presentation (likely on Wednesday).

• Anybody in panic mode?

Troy and Owen will meet at 12:00 tomorrow to record the Project Proposal Presentation

Meeting Time: 5pm Meeting is Online, Discord

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

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

Lots to do here.

First we need to add all tasks we want to do to the Kanban Board, Sprint, and Product Backlog Document. (20min)

From there we can start deciding how to delegate, what to prioritize, and what needs to be done as a group. (20min)

Actually doing these tasks can wait depending on how long it takes to get ourselves organized.

Easy Tasks

• Correct based on feedback on Deliverable 1
• Sprint & Product Backlog
• Kanban Board
• Sprint Review
• Github contribution (make sure people are hitting that "commit" button as we program)

Hard Tasks

• Fill in rest of SRS and correct mistakes
• Architecture design document (which includes a "UML package diagram"). Greg has this https://docs.google.com/document/d/1S7R3Tt6wKMN1nIgka4z8HZBGtxmpXdrA/edit as a template to use.
• Lots of Use Case Diagrams/Models. We need 10-20 use case descriptions and 2-4 use case diagrams (which each have 3-5 use cases). Again, Greg provided template https://docs.google.com/document/d/1jBaLHNLAAEPAqN7BCqZspq04X625YcIY/edit and some examples; https://drive.google.com/file/d/1_r0T_X7xg1zB9Vnt0CAREqIjXAOmi0MV/view
• Programming. Recommended that we start with the UI but we need to discuss this (like who will do what).

Get back to updating project description document for deliverable 1 revisions

Troy will focus on the architecture design document

Owen will focus on the use case description/modeling

Brennan and Graham will focus on developing the front end/UI

This was a work meeting

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

• Check with everyone to see how everyone did over the past couple of days.
• Fill in the gaps (most likely we'll all need to chip in for use cases to save Owen some suffering)
• Do a final once-over with the requirements to make sure everything looks good.
• Do a double check on the backlog documents, assign how much people did with each respective task.

• Start planning early. Let's look at the document and see what we need to get done.

Meeting Time: 5pm Meeting is Online, Discord

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

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

• Yep, that's it. We'll work on it until people are either done or dead. Maybe both.

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

• Final check-in. Make sure everyone is caught up.

• Let's take a look over any revisions posted for the deliverable 2. Then start delegating things.

Meeting Time: 5pm Meeting is Online, Discord

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

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

• Talk about what went wrong with our Use Case stuff
• Delegate Fixing.

• Do a quick confirmation with everyone what documents we need to do and what that entails.

• Discuss what we should aim for by the due date, and who will be in charge of what.

• Follow comments Greg left on use case descriptions and add use case for “write a review”

• Revise Deliverable 2 where Greg has commented/taken points off

• Create sequence diagrams

• Everyone work on fixing components task before programming site

Meeting Time: 3pm (theoretically) Meeting is in person and online, Discord

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

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

• Delegate stuff

• Match Process - Brennan
• Review Feedback - Owen Bellow
• Making Review Process - Troy
• Delete/ Modify Review - Troy
• Login / Log out - Troy
• Register - Graham
• Modify Profile - Troy

• Use Case Stuff - Owen

• Graham and Brennan work on getting fundamental form of match system.

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

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

Meeting Time: 1pm Meeting is in person and online, Discord

• Role call, how far did everyone get with their respective tasks?
• Everyone work on any tasks that remain incomplete.
• Quality Check, make sure everything is done (check both assignment submit link and syllabus).

• We have a long break before the next due date. Let's use that to get some work done on programming.

Ask questions early to Professor Nelson

Split tasks up more on the Zenhub board

Define how the match system will work

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

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

Making issues on the zenhub board. Identify everything that we want to get done, separating into smaller tasks, then decide what to be done individually and what to be done as a group.

What do we need to fix?

Aim for a completion date before Friday, including a double check time. This way we can bother Greg to make sure it's correct.

We need to diagram, envision, document, how the match system is suppose to work.

What are some components that we want to make this week?

Updated Zenhub and assigned people to jobs

Match system sequence diagram must be fixed. Still working on specifying the match system

For at least half an hour Monday, everyone will work on Use Case Descriptions/Diagrams

Troy will work on login, navbar, and routes

Owen will work on color scheme and front page

Brennan will work on match system search design

Graham will work on Create Review page

• Let's buckle down and set up a plan to deal with this section. Identify all the material we can use for examples (and list them here). Have everyone work on them at least a little because it's clearly a blind spot for us.

• Quick glance through to make sure there aren't any more classes involved in the domain model we started in class.

• How's everyone doing on their respective spots? How far do you think you'd be able to get by Sunday meeting?

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

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

• Since we had a short Friday we've had to push this off until around now. But we need to get this done. I know it's painful but I suggest we don't end the meeting until this is done at minimum. We need to have something ready for Greg to check by the end of this day that way we have time to get corrections in.

• Class Diagram
• Fixing Sequence diagram with the new plan for the match system.
• Fixing old documents based on changes that we've made.
• Programming tasks.

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

• Owen Bellow
• Brennan Poitras
• Troy Schotter
• Graham Bridges
• Sean Whynot [Absent]

• Need to set up a system to create courses. Refer to the domain diagram to identify what pieces of information we need.
• Lots of Graphical UI work to be done
• Class page (where you look at an individual class) and Review Page (where you look at an individual review) needs to be started
• Match system page and LeaveReview Page needs to start having functionality.
• Let's try to make sure each person is working on something different to avoid overlap.

• Where is everyone at?
• Friday lab meeting to churn out a lot of work and help each other get through blocks.

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

• Owen Bellow
• Brennan Poitras [absent]
• Troy Schotter
• Graham Bridges
• Sean Whynot

• How are you doing? Where are you at?

• Lets look at any and all feedback posted. (check Miro, shared drive documentation, and brightspace)

• New Thing to add (pulled from syllabus):

Create the Detailed Design document, with design patterns and design class diagram (35% of Deliverable 5).

You need to pick 1 – 2 design patterns related to your application development, show how they are implemented with class diagrams, and explain and justify your decision.

You will also show an overview design of your application with a class diagram. Your DCD need to match your development and shows how design patterns are used.

You may break your DCD into more than two diagrams if it is too large.

[Assigned for everyone, look through Class 21 and 22 slides]

• Confirm programming assignments, check which ones people will prioritize.

• Make sure to update zenhub once we're done discussing

• Command pattern for an undo system regarding class scheduling.

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

• Owen Bellow
• Brennan Poitras
• Troy Schotter
• Graham Bridges
• Sean Whynot [absent]

We're at the endgame let's go over what we need to do (as a group) and when they need/should to be done by.

• What are our new documents that we need to complete, and who wants to get started on them?
• We have a bunch of documents to update based on some changes we've made regarding both the backend and how the match system is envisioned.

• What is the state of our code at this point? How far do we think we can realistically get to? This will also go into how we answer the "Future Plans" document.
• Aim for the slides to be done by Sunday so we have time to correct mistakes and create the presentation.

• Double check and confirm with everyone when they'll be able to meet. Be it online or in person.

[Meeting 1pm Saturday to clean up Deliverable 6]

[Meeting 1pm Sunday if Owen and Graham are alive preferred smaller meeting]

[Aim to record 5pm Monday]

• Before we end this meeting, one final update of the kanban board related to everything discussed here.