feat: revamp and refactor courses to support multiple aggregation views

Ghost commented

2026-04-12 06:20:34 +00:00

(Migrated from codeberg.org)

Features:

Add a Summary, Aggregate By Instructor, and All Semesters select menu to view FCE data on various levels of granularity
Abbreviate semesters (Fall 2025 -> F25)
- Since the N prefix for summers will no longer be used in Summer 2026, we use M only. This solves the problem of not knowing which summer half a course is in from the FCE data
Strikethrough summer semesters excluded in FCE calculations

Refactors:

Generalize EmbedPaginator to work with other components, such as select menus
Split courses subcommands into their own commands, each in their own file (part of #92)
Merge FCE data with the same instructor and semester
Move operatorParser.ts from modules to utils (closes #96)

Performance:

Cache FCE data and aggregate FCEs on startup (closes #71)

Features: - Add a Summary, Aggregate By Instructor, and All Semesters select menu to view FCE data on various levels of granularity - Abbreviate semesters (Fall 2025 -> F25) - Since the N prefix for summers will no longer be used in Summer 2026, we use M only. This solves the problem of not knowing which summer half a course is in from the FCE data - Strikethrough summer semesters excluded in FCE calculations Refactors: - Generalize `EmbedPaginator` to work with other components, such as select menus - Split courses subcommands into their own commands, each in their own file (part of #92) - Merge FCE data with the same instructor and semester - Move `operatorParser.ts` from `modules` to `utils` (closes #96) Performance: - Cache FCE data and aggregate FCEs on startup (closes #71)

Ghost commented

2026-04-13 21:54:53 +00:00

(Migrated from codeberg.org)

I do somewhat disagree with splitting courses up without implementing a way to still reach those commands through a central location, but we can deal with that later (when me or someone else does that command refactor thing)

I agree, in another PR we should move these courses commands into src/courses, and then have the command handler recursively look through folders to find them

I think we shouldn't exactly name it utils/index.ts but that only really matters when we have other utils files

For these extremely small functions, I think it's fine to go in index.ts, but if we accumulate more course-related things we need to put in utils then I'd prefer making a different file too

> I do somewhat disagree with splitting courses up without implementing a way to still reach those commands through a central location, but we can deal with that later (when me or someone else does that command refactor thing) I agree, in another PR we should move these courses commands into `src/courses`, and then have the command handler recursively look through folders to find them > I think we shouldn't exactly name it utils/index.ts but that only really matters when we have other utils files For these extremely small functions, I think it's fine to go in `index.ts`, but if we accumulate more course-related things we need to put in `utils` then I'd prefer making a different file too

Ghost commented

2026-04-14 05:26:44 +00:00

(Migrated from codeberg.org)

I agree, in another PR we should move these courses commands into src/courses, and then have the command handler recursively look through folders to find them

For the sake of user usability, we may not want to expand the commands just to recompress them again at a later date, in my opinion. Perhaps we can get the PR for this before we deploy this one

> > I agree, in another PR we should move these courses commands into `src/courses`, and then have the command handler recursively look through folders to find them > For the sake of user usability, we may not want to expand the commands just to recompress them again at a later date, in my opinion. Perhaps we can get the PR for this before we deploy this one

Ghost commented

2026-04-14 07:59:35 +00:00

(Migrated from codeberg.org)

For the sake of user usability, we may not want to expand the commands just to recompress them again at a later date, in my opinion. Perhaps we can get the PR for this before we deploy this one

This is intentional. We want the commands to be /fce, /course, /syllabus, etc rather than subcommands /courses fce, /courses course-info, etc, as discussed in #92.

> For the sake of user usability, we may not want to expand the commands just to recompress them again at a later date, in my opinion. Perhaps we can get the PR for this before we deploy this one This is intentional. We want the commands to be `/fce`, `/course`, `/syllabus`, etc rather than subcommands `/courses fce`, `/courses course-info`, etc, as discussed in #92.

Ghost commented

2026-04-14 13:56:45 +00:00

(Migrated from codeberg.org)

It would be a bad change in user-space if it left /courses, and then later came back with /courses

https://lkml.org/lkml/2012/12/23/75

It would be a bad change in user-space if it left `/courses`, and then later came back with `/courses` https://lkml.org/lkml/2012/12/23/75

Ghost commented

2026-04-14 15:08:10 +00:00

(Migrated from codeberg.org)

I think there is a misunderstanding - we are permanently moving from /courses fce to /fce. There will not be a /courses command in future versions of the bot. Whether or not we want to change the internal folder structure to reflect this is up for discussion, but I believe these courses subcommands should be changed into separate commands moving forward

I think there is a misunderstanding - we are permanently moving from `/courses fce` to `/fce`. There will not be a `/courses` command in future versions of the bot. Whether or not we want to change the internal folder structure to reflect this is up for discussion, but I believe these courses subcommands should be changed into separate commands moving forward

Ghost commented

2026-04-14 16:24:35 +00:00

(Migrated from codeberg.org)

Why would it be bad to have two versions of the command (e.g. /courses fce and /fce)? It would allow users to more easily discern all of the course commands available but still give a shortcut command.

Why would it be bad to have two versions of the command (e.g. `/courses fce` and `/fce`)? It would allow users to more easily discern all of the course commands available but still give a shortcut command.

Ghost commented

2026-04-14 17:51:30 +00:00

(Migrated from codeberg.org)

Providing two ways to do the same thing adds clutter to the commands list and will cause confusion about what is the difference between the two. /fce is already descriptive; we don't need to categorize them based on whether it is from courses or not.

Providing two ways to do the same thing adds clutter to the commands list and will cause confusion about what is the difference between the two. `/fce` is already descriptive; we don't need to categorize them based on whether it is from courses or not.

Ghost commented

2026-04-15 06:38:22 +00:00

(Migrated from codeberg.org)

Personally I'm on the wagon of putting it all under courses for the sake of macroscopic organization across the bot. I think effectively categorizing functions within an overarching command gives a cleaner UX. For example, the user will be shown all the course commands when they type /course, so they are implicitly informed of all functionality. You can end up with a "lost command" or confusion on functionality if you spread it out. Just my 2 cents tho

Ghost commented

2026-04-15 06:39:57 +00:00

(Migrated from codeberg.org)

Additionally, my understanding of #92 is to put sub command code in different files in a shared parent folder for the command, not separate out the commands themselves.

Ghost commented

2026-04-15 13:33:51 +00:00

(Migrated from codeberg.org)

For what it's worth, we can still have subcommands in individual folders without registering the path as that command.

Ghost commented

2026-04-16 01:06:30 +00:00

(Migrated from codeberg.org)

For what it's worth, we can still have subcommands in individual folders without registering the path as that command.

Yep this was what I was thinking

We can put a poll up for /fce vs /courses fce if you guys want

> For what it's worth, we can still have subcommands in individual folders without registering the path as that command. Yep this was what I was thinking We can put a poll up for `/fce` vs `/courses fce` if you guys want

Ghost commented

2026-04-21 02:16:27 +00:00

(Migrated from codeberg.org)

That's a good idea, we should do that.

Ghost commented

2026-04-23 22:29:45 +00:00

(Migrated from codeberg.org)

~~Will add an alias feature and move commands back to the courses folder~~

Held for further discussion

~~Will add an alias feature and move commands back to the `courses` folder~~ Held for further discussion

Ghost commented

2026-05-08 19:02:17 +00:00

(Migrated from codeberg.org)

Decided on Discord

Rows
Columns

feat: revamp and refactor courses to support multiple aggregation views #152