Figure out and document how the course/section/meeting hierarchy works.

[rpruim]

I've just begun digging into this a little bit. But it would be good to have it clearly documented somewhere. And we should check that we aren't assuming things are fixed at that course level that could be different at the section level.

[rpruim]

Related to #185?

[charkour]

A course (STAT-343) can have multiple sections (A, B, C), and sections can have multiple meetings (Room number and time).

Yeah, it isn't documented outside of the code itself. In this file, the Course contains an array of Meetings and each meeting has an array of Sections.

[charkour]

Rather than adding this to a readme, I'd rather opt for making the typescript files easier to read (self-documenting).

But I'm open to your thoughts as well!

[rpruim]

Given the role that standard meeting patterns seem to have in the new schedule, we might want to separate that out into its own data type as part of a meeting. So a meeting would have a meeting pattern plus a location and some other stuff. Something to keep in mind as we refactor, improve checks for non-standard meeting patterns, etc.

[charkour]

Can't a meeting pattern be represented by an array of meetings? That is why that data type is an array.

From my (limited) understanding of Meeting Patterns, this is solved by the current data type and no change is needed. What we could change is updating the UI to make it easier to manage meeting patterns which will be stored as a meeting array.

[rpruim]

No what you are calling a meeting is what I'm calling a meeting pattern. A course can use multiple meeting patterns:

MWF @ 9 in Room A for 65 mins -- pattern 1

R @ 12:30 in Room B for 65 mins -- pattern 2

Eventually we may want to handle trickier things like a course that meats

MW @ 8 in Room A for 65 mins F @ 8 in Room B for 65 mins

That should probably be considered a legit way to meet MWF @ 8 (a legal pattern for 65 minutes classes), but currently the MW part will get flagged because F is missing. The F part won't get flagged (because it uses exactly one slot).

It's a bit of a balance to get the correct amount of flagging.

[charkour]

Thanks for the explanation.

With the current data structure, your first example would be stored as four different meetings where the idea of the pattern is implicitly known based on our DSL definition of pattern.

[rpruim]

@charkour, That's not what I think I'm seeing when I explore the data. I see, for exmple:

A "meeting" has an array of days. A section can have an array of meetings, but each meeting reflects a combination of days that use the same time and location. Workday refers to this as a meeting pattern.

I like the meeting pattern lingo, and perhaps a future refactor could modify our data labeling to reflect it.

PS. Is there a way to copy and paste out the console in Chrome or Firefox and get a JSON representation. I tried to copy and paste and got an ugly format. Hence the screen shot.

[charkour]

Okay, looks like I was wrong. Thanks for looking into that.