/
Architectural Design Questions

Architectural Design Questions

This document lists the main technical and design questions we need to answer to build a unified user grouping system. This system aims to combine and eventually replace existing group types like cohorts, course groups, and teams. It should allow flexible ways to group users, support plugin-based extensions, and work well at scale.

The questions in this document cover topics such as the data model, how group membership is calculated, how it connects with Aspects, how to manage performance, and how groups behave in different situations.

Not all of these questions need to be answered right away. They are meant to guide the project. As we move through research, design, and implementation, the answers will become clearer and will be documented along the way.

⚠️ This is a living document — more questions and answers may be added as the project evolves. Anyone involved in the project can leave comments or suggest new questions to help us cover all important areas.

Lessons from Existing User Groups

  • What can we learn from the current implementation of user groups, cohorts, and teams in Open edX?

    • The current mechanisms were designed independently, which has led to duplicated logic and poor extensibility.

    • There are multiple configuration points across the platform for managing current mechanisms, which can create confusion for different users (course authors, admins, students).

  • What technical or design issues from the current system should we avoid when building the unified grouping model?

    • There are multiple terms used to describe the same concept. For example, “Team Sets” are also referred to as “Topics” or “Groups,” which causes inconsistency.

    • Data is stored in different places: for instance, Team Sets are saved within the course block (in JSON), while Teams are Django models.

    • There is no clear or easily accessible way to retrieve which users belong to which groups.

  • Do group types (cohorts, teams…) differ in definition or only in behavior (e.g., exclusivity, ...)?

    • They differ in both. The data models are distinct between types, and their behaviors diverge in some cases (e.g., mutual exclusivity, group visibility).

  • What is the minimal shared structure that all grouping mechanisms (such as teams, cohorts, …) have?

    • All grouping mechanisms rely on user partitions to control content access.

    • There is a membership relationship between users and groups in Cohorts and Teams. However, in Enrollment Tracks, no explicit membership model exists—assignment is inferred from the user’s enrollment mode.

More details in: Technical Exploration of Existing User Grouping Mechanisms & Technical Exploration Questions & Answers

Model Design and Structure

  • Can group roles and behaviors be compared to roles and permissions in the system? Can behaviors be stacked or combined to create new group types?

  • Will the system support different types of user groups with different behaviors (like content access, discussion grouping, messaging), or is there only one general type of user group?

  • Should constraints like mutual exclusivity of group membership (e.g., a user can only belong to one group of a certain type) be enforced? If so, at what level should they be implemented — in the data model, at the business logic layer, or elsewhere?

    • This is still in discussion, TBD

  • What kind of historical metadata is relevant and should be kept for each user group?

  • How relevant is managing historical tracking for groups and user's membership?

  • Can the group's criteria change after it was created?

    • Yes!

  • If no criteria are defined for a group, does that make it a manual group by default?

  • How do we store additional parameters or configurations needed by the criteria without overloading the base model?

  • How will user groups be uniquely identified across scopes (e.g., course/org/instance)? Should group IDs be globally unique or scoped?

    • TBD, too detailed to answer for now

Criteria Definition and Evaluation

Extensibility

Evaluation Frequency and Sync

Cross-System Consistency

Data Sources and Backend Integration

Performance and Scalability

Overrides

  • Can instructors manually remove users from dynamic groups, overriding the criteria?

    • No!

  • If so, how should we record and respect manual overrides so that users aren't re-added during refresh?

    • No overrides allowed

Use Cases and Role Differences

Linking key user group use cases here.

  • Should we clearly distinguish between instructor-managed groups (like cohorts) and student-managed groups (like some teams)?

    • TBD, but at the moment the answer is only instructor managed

  • In student-managed groups, how do we define eligibility criteria (e.g., filter who can see or join a group)?

    • TBD, but at the moment the answer is only instructor managed

  • Should group behaviors (e.g., like cohorts) enforce mutually exclusive membership through criteria? For example, what happens if Group A is defined by “last login < 10 days” and Group B by “country = Spain” and a user matches both? How should we handle and validate criteria combinations that are logically incompatible or mutually exclusive?

  • In student-managed groups (e.g., like teams), how should criteria be used? Should the system evaluate eligibility when the user attempts to join the group (join-time validation)? Or should group visibility be filtered in advance so that only eligible users can see and join those groups?

Umbrella Model

  • Should legacy group types (cohorts, teams) become specializations of the unified model, or should they be deprecated over time?

    • They should be deprecated over time and replaced with the unified model version.

  • Should we keep the concepts of teams and cohorts to better organize and explain group behaviors, instead of listing features without a clear structure. For example, saying that teams allow collaboration and cohorts control content visibility?

  • Could course teams choose how they want their group to behave? For example, selecting "behaves like a team" to enable collaboration or "behaves like a cohort" to control access to content? Teams can also be used to control access to content, so considering “group types” might not be a good approach? There’s overlapping functionality, so is it still confusing?

  • Can we create new group types by combining or reusing existing behaviors, such as a group that supports collab (like teams) and content access (like cohorts)? This already exists with teams.

  • How could we support adding new behaviors in the future, such as making group-based grading available for any group type to adopt?

  • Would it make sense to treat these capabilities as built-in to user groups, without needing to define a specific “type”?

Migration Path

  • User grouping (for now) would be an additional model that includes criteria to select users. How can we connect this model to the existing ones, while respecting the constraints of each?