Looks like this work is already well along. See app/models/classroom_program_course.rb

There should be a database table for course type, that we can query for a list of valid types.

In a later phase, we could provide an admin UI for creating new group types.

The Course base class should not have any knowledge of specific course types.

In T125773#1999762, @awight wrote:

There should be a database table for course type, that we can query for a list of valid types.

In a later phase, we could provide an admin UI for creating new group types.

Interesting idea... I suppose we could have various modules defining different behaviors — different scopes for course.revisions and the other things specified currently via the ClassroomProgramCourse and other type models. Seems like a lot of UI and refactoring for a use case — arbitrary new course types — that we can probably get very far without.

In T125773#2000049, @Ragesoss wrote:

Seems like a lot of UI and refactoring for a use case — arbitrary new course types — that we can probably get very far without.

I agree, we're best off with the absolute minimum of course types to start with--most of all, just the freeform "generic" type, which we can extend to be useful for all of the most common cases. Arbitrary types and course metadata would come much later if ever.

All I care about for the MVP is that we can add more properties to course type, and I imagine that can be done in the concrete subclasses with or without database backing.