/
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: https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4928962617 & https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4951441413

Model Design and Structure

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?