diff --git a/docs/openedx_learning/decisions/0001-competency-criteria-location.rst b/docs/openedx_learning/decisions/0001-competency-criteria-location.rst index 65a9e2177..1b2590f0b 100644 --- a/docs/openedx_learning/decisions/0001-competency-criteria-location.rst +++ b/docs/openedx_learning/decisions/0001-competency-criteria-location.rst @@ -9,36 +9,36 @@ Competency Based Education (CBE) requires that the LMS have the ability to track Decisions --------- -CBE Competency Criteria, Student Competency Criteria Status, and Student Competency Status values should go in the openedx-learning repository as there are broader architectural goals to refactor as much code as possible out of the edx-platform repository into the openedx-learning repository such that it can be designed in a way that is easy for plugin developers to utilize. Additionally, we intend to treat CBE features as core features of Open edX rather than optional plugins, and as a result, CBE competency criteria and learner status should live in the learning core rather than in a separate new repo. +CBE Competency Criteria, Student Competency Criteria Status, and Student Competency Status values should go in the openedx-core repository as there are broader architectural goals to refactor as much code as possible out of the openedx-platform repository into the openedx-core repository such that it can be designed in a way that is easy for plugin developers to utilize. Additionally, we intend to treat CBE features as core features of Open edX rather than optional plugins, and as a result, CBE competency criteria and learner status should live in the learning core rather than in a separate new repo. -Given the current refactor of openedx-learning (see :ref:`openedx-content-adr-0010`), we will place CBE code inside the top-level ``openedx_learning`` app as an applet, alongside Learning Pathways. The intended layout is: +Given the current refactor of openedx-core (see :ref:`openedx-content-adr-0010`), we will place CBE code inside a new top-level ``openedx_learning`` app as an applet, alongside Learning Pathways. The intended layout is: :: src/ - openedx_catalog - openedx_content - openedx_learning - openedx_tagging - src/openedx_learning/applets/learning_pathways - src/openedx_learning/applets/cbe + openedx_catalog/ + openedx_content/ + openedx_learning/ + applets/ + cbe/ + learning_pathways/ + openedx_tagging/ -The umbrella ``openedx_learning`` app will import from those applets in the same way that ``openedx_content`` does today. +The umbrella ``src/openedx_learning`` app will aggregate its applets into a single Django app and Python API, similar to the internal structure of ``src/openedx_content`` today. -This placement also keeps CBE close to shared learning-domain concepts that are already part of ``openedx_learning``, minimizing duplication and cross-package import issues. A separate repo would have added packaging/CI/release/migration coordination overhead for a tightly coupled core feature. Finally, applets provide a clean migration path: we can evolve or split responsibilities within ``openedx_learning`` later without the extra cost of deprecating a standalone package. +This placement will keep CBE close to shared learning-domain concepts like ``learning_pathways``. Rejected Alternatives --------------------- -1. Put all CBE competency criteria and learner status in a single ``openedx_learning`` app under ``openedx_learning/apps/competency_criteria`` +1. Put all CBE competency criteria and learner status in a single ``openedx-core`` app under ``src/openedx_competency_criteria`` - Pros: - Keeps a single cohesive Django app for authoring criteria and storing learner status, reducing cross-app dependencies and simplifying migrations and APIs. - - Keeps Open edX-specific models (users, course identifiers, LMS/Studio workflows) out of the standalone ``openedx_tagging`` package and avoids forcing an authoring-only app to depend on learner runtime data. - Cons: - - Does not align with the applet-based top-level structure being created in openedx-learning (``openedx_learning/applets/...``). -2. edx-platform repository + - Does not align with the applet-based top-level structure (``src/openedx_learning/applets/...``). +2. openedx-platform repository - Pros: This is where all data currently associated with students is stored, so it would match the existing pattern and reduce integration work for the LMS. - - Cons: The intention is to move core learning concepts out of edx-platform (see :ref:`openedx-core-adr-0001`), and keeping it there makes reuse and pluggability harder. -3. All code related to adding Competency Criteria to Open edX goes in openedx-learning/openedx\_learning/apps/authoring/competency\_criteria + - Cons: The intention is to move core learning concepts out of openedx-platform (see :ref:`openedx-core-adr-0001`), and keeping it there makes reuse and pluggability harder. +3. All code related to adding Competency Criteria to Open edX goes in ``src/openedx_content/applets/competency_criteria`` - Pros: - Tagging and competency criteria are part of content authoring workflows as is all of the other code in this directory. - All other elements using the Publishable Framework are in this directory. @@ -46,13 +46,13 @@ Rejected Alternatives - We want each package of code to be independent, and this would separate competency criteria from the tags that they are dependent on. - Competency criteria also includes learner status and runtime evaluation, which do not fit cleanly in the authoring app. - The learner status models in this feature would have a ForeignKey to settings.AUTH_USER_MODEL, which is a runtime/learner concern. If those models lived under the authoring app, then the authoring app would have to import and depend on the user model, forcing an authoring-only package to carry learner/runtime dependencies. This may create unwanted coupling. -4. New Competency Criteria Content tables will go in openedx-learning/openedx_learning/openedx_tagging/core/competency_criteria. New Student Status tables will go in openedx-learning/student_status. +4. New Competency Criteria Content tables will go in ``src/openedx_tagging/competency_criteria``. New Student Status tables will go in ``src/openedx_student_status``. - Pros: - Keeps competency criteria in the same package as the tags that they are dependent on. - Cons: - - `openedx_tagging` is intended to be a standalone library without Open edX-specific dependencies (see :ref:`openedx-tagging-adr-0002`) competency criteria would violate that boundary. + - ``src/openedx_tagging`` is intended to be a standalone library without Open edX-specific dependencies (see :ref:`openedx-tagging-adr-0002`) competency criteria would violate that boundary. - Splitting Competency Criteria and Student Statuses into two apps would require cross-app foreign keys (e.g., status rows pointing at criteria/tag rows in another app), migration ordering and dependency declarations to ensure tables exist in the right order, and shared business logic or APIs for computing/updating status that now must live in one app but reference models in the other. -5. Split competency criteria and learner statuses into two apps inside openedx-learning/openedx\_learning/apps (e.g., competency\_criteria and learner\_status) +5. Split competency criteria and learner statuses into two apps inside ``src`` (e.g., ``src/openedx_competency_criteria`` and ``src/openedx_learner_status``) - Pros: - Clear separation between authoring configuration and computed learner state. - Could allow different storage or scaling strategies for status data. @@ -72,7 +72,7 @@ Rejected Alternatives - Cons: - Adds packaging and versioning overhead for a tightly coupled domain. - Increases coordination cost for migrations and API changes. -8. Migrate grading signals to openedx-events now and have openedx-learning consume events directly +8. Migrate grading signals to openedx-events now and have openedx-core consume events directly - Pros: - Aligns with the long-term direction of moving events out of edx-platform. - Avoids a shim app in edx-platform and reduces tech debt.