docs: rename assessment criteria to competency criteria

Author: mgwozdz-unicon

…ns/0021-assessment-criteria-location.rst …ns/0021-competency-criteria-location.rstdocs/decisions/0021-assessment-criteria-location.rst renamed to docs/decisions/0021-competency-criteria-location.rst docs/decisions/0021-assessment-criteria-location.rst renamed to docs/decisions/0021-competency-criteria-location.rst

@@ -1,13 +1,13 @@
-21. Where in the codebase should CBE assessment criteria go?
+21. Where in the codebase should CBE competency criteria go?
 ============================================================
 
 Context
 -------
-Competency Based Education (CBE) requires that the LMS have the ability to track learners' mastery of competencies through the means of assessment criteria. For example, in order to demonstrate that I have mastered the Multiplication competency, I need to have earned 75% or higher on Assignment 1 or Assignment 2\. The association of the competency, the threshold, the assignments, and the logical OR operator together make up the assessment criteria for the competency. Course Authors and Platform Administrators need a way to set up these associations in Studio so that their outcomes can be calculated as learners complete their materials. This is an important prerequisite for being able to display competency progress dashboards to learners and staff to make Open edX the platform of choice for those using the CBE model.
+Competency Based Education (CBE) requires that the LMS have the ability to track learners' mastery of competencies through the means of competency criteria. For example, in order to demonstrate that I have mastered the Multiplication competency, I need to have earned 75% or higher on Assignment 1 or Assignment 2\. The association of the competency, the threshold, the assignments, and the logical OR operator together make up the competency criteria for the competency. Course Authors and Platform Administrators need a way to set up these associations in Studio so that their outcomes can be calculated as learners complete their materials. This is an important prerequisite for being able to display competency progress dashboards to learners and staff to make Open edX the platform of choice for those using the CBE model.
 
 Decisions
 ---------
-CBE Assessment Criteria, Student Assessment 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 assessment 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-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.
 
 Given the current refactor of openedx-learning (see `0020-merge-authoring-apps-into-openedx-content.rst <0020-merge-authoring-apps-into-openedx-content.rst>`_), we will place CBE code inside the top-level ``openedx_learning`` app as an applet, alongside Learning Pathways. The intended layout is:
 
@@ -27,7 +27,7 @@ This placement also keeps CBE close to shared learning-domain concepts that are
 
 Rejected Alternatives
 ---------------------
-1. Put all CBE assessment criteria and learner status in a single ``openedx_learning`` app under ``openedx_learning/apps/assessment_criteria``  
+1. Put all CBE competency criteria and learner status in a single ``openedx_learning`` app under ``openedx_learning/apps/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.  
@@ -36,21 +36,21 @@ Rejected Alternatives
 2. edx-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 `0001-purpose-of-this-repo.rst <0001-purpose-of-this-repo.rst>`_), and keeping it there makes reuse and pluggability harder.  
-3. All code related to adding Assessment Criteria to Open edX goes in openedx-learning/openedx\_learning/apps/authoring/assessment\_criteria  
+3. All code related to adding Competency Criteria to Open edX goes in openedx-learning/openedx\_learning/apps/authoring/competency\_criteria  
     - Pros:   
-        - Tagging and assessment criteria are part of content authoring workflows as is all of the other code in this directory.  
+        - 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.  
     - Cons:   
-        - We want each package of code to be independent, and this would separate assessment criteria from the tags that they are dependent on.  
-        - Assessment criteria also includes learner status and runtime evaluation, which do not fit cleanly in the authoring app.  
+        - 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 Assessment Criteria Content tables will go in openedx-learning/openedx_learning/openedx_tagging/core/assessment_criteria. New Student Status tables will go in openedx-learning/student_status.  
+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.  
     - Pros:  
-        - Keeps assessment criteria in the same package as the tags that they are dependent on.  
+        - 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 `0007-tagging-app.rst <0007-tagging-app.rst>`_) assessment criteria would violate that boundary.  
-        - Splitting Assessment 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 assessment criteria and learner statuses into two apps inside openedx-learning/openedx\_learning/apps (e.g., assessment\_criteria and learner\_status)  
+        - `openedx_tagging` is intended to be a standalone library without Open edX-specific dependencies (see `0007-tagging-app.rst <0007-tagging-app.rst>`_) 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)  
     - Pros:  
         - Clear separation between authoring configuration and computed learner state.  
         - Could allow different storage or scaling strategies for status data.