From 77f631a843de1cac6c99d86ce23eea05a975b376 Mon Sep 17 00:00:00 2001 From: Giovanni Cimolin Date: Wed, 19 Apr 2023 14:22:26 +0100 Subject: [PATCH 1/4] docs: Add content tagging decision ADR --- docs/decisions/0004-content-tagging.rst | 44 +++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 docs/decisions/0004-content-tagging.rst diff --git a/docs/decisions/0004-content-tagging.rst b/docs/decisions/0004-content-tagging.rst new file mode 100644 index 000000000..3e960d6db --- /dev/null +++ b/docs/decisions/0004-content-tagging.rst @@ -0,0 +1,44 @@ +3. Content Tagging +================== + +Context +------- + +Tagging content is central to enable content re-use, facilitate the implementation of flexible content structures different from the current implementation and allow adaptive learning in the Open edX platform. + +Content tagging should be classified as "kernel" component following `OEP-57's `_ guidelines, as a baked-in feature of the platform. + +Decision +-------- + +Implement the new tagging service as a pluggable django app, and installed alongside learning-core as a dependency in the edx-platform. + +Tagging data models will follow the guidelines for this repository, and focus on extensibility and flexibility. + +Since some use cases for content tagging are not considered "kernel" (like providing data for a marketing site), a generic mechanism to differentiate those uses cases will be built, +and proper Python and REST APIs will be provided, to different taxonomies/tags for the same content. + + +Rejected Alternatives +--------------------- + +Implementing tagging as Discovery service plugin +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Discovery is already used as the source of truth place for course/program/block metadata in the previous implementations, so keeping it here means keeping the platform metadata management "consistent" (specially since it needs to work with all kinds of contents - from atomic learning units all the way up to courses). + +Concerns: +#. The course discovery repository is not well documented and has code that is only used by edX/2U. +#. Some implementations are tied to specific closed-source services (example: `openedx/taxonomy-connector `_ uses a 3rd party closed-source service to tag video blocks automatically). +#. The data flow from the discovery service is confusing, and evolved as the needs for that repo changed. `Reference `_. +#. Many people prefer/need to run the platform without the discovery service. + +Implement tagging as a new IDA +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A new IDA dedicated for tagging would represent a break from the current codebases and force implementation using REST APIs. +This option adds extra complexity without a good compelling reason for it. + +Concerns: +#. One more app to host: maintenance cost increases over time. +#. Extra response time between services when handling synchronous operations related to tagging. From 45579c9adc849b6695e09dc199708a879897b0b6 Mon Sep 17 00:00:00 2001 From: Giovanni Cimolin Date: Wed, 19 Apr 2023 14:23:30 +0100 Subject: [PATCH 2/4] nit: fix ADR number --- docs/decisions/0004-content-tagging.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decisions/0004-content-tagging.rst b/docs/decisions/0004-content-tagging.rst index 3e960d6db..bb5dfa223 100644 --- a/docs/decisions/0004-content-tagging.rst +++ b/docs/decisions/0004-content-tagging.rst @@ -1,4 +1,4 @@ -3. Content Tagging +4. Content Tagging ================== Context From 384dc49820389851d911173612b13a9108ae3217 Mon Sep 17 00:00:00 2001 From: Giovanni Cimolin Date: Wed, 19 Apr 2023 14:24:07 +0100 Subject: [PATCH 3/4] nit: Fix formatting --- docs/decisions/0004-content-tagging.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/decisions/0004-content-tagging.rst b/docs/decisions/0004-content-tagging.rst index bb5dfa223..3de14e0c8 100644 --- a/docs/decisions/0004-content-tagging.rst +++ b/docs/decisions/0004-content-tagging.rst @@ -28,6 +28,7 @@ Implementing tagging as Discovery service plugin Discovery is already used as the source of truth place for course/program/block metadata in the previous implementations, so keeping it here means keeping the platform metadata management "consistent" (specially since it needs to work with all kinds of contents - from atomic learning units all the way up to courses). Concerns: + #. The course discovery repository is not well documented and has code that is only used by edX/2U. #. Some implementations are tied to specific closed-source services (example: `openedx/taxonomy-connector `_ uses a 3rd party closed-source service to tag video blocks automatically). #. The data flow from the discovery service is confusing, and evolved as the needs for that repo changed. `Reference `_. @@ -40,5 +41,6 @@ A new IDA dedicated for tagging would represent a break from the current codebas This option adds extra complexity without a good compelling reason for it. Concerns: + #. One more app to host: maintenance cost increases over time. #. Extra response time between services when handling synchronous operations related to tagging. From d1922b2360f08ffde2361eebd4e9dd6295dad158 Mon Sep 17 00:00:00 2001 From: Giovanni Cimolin Date: Wed, 19 Apr 2023 14:29:04 +0100 Subject: [PATCH 4/4] nit: remove line break --- docs/decisions/0004-content-tagging.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/decisions/0004-content-tagging.rst b/docs/decisions/0004-content-tagging.rst index 3de14e0c8..dff13aec1 100644 --- a/docs/decisions/0004-content-tagging.rst +++ b/docs/decisions/0004-content-tagging.rst @@ -15,8 +15,7 @@ Implement the new tagging service as a pluggable django app, and installed along Tagging data models will follow the guidelines for this repository, and focus on extensibility and flexibility. -Since some use cases for content tagging are not considered "kernel" (like providing data for a marketing site), a generic mechanism to differentiate those uses cases will be built, -and proper Python and REST APIs will be provided, to different taxonomies/tags for the same content. +Since some use cases for content tagging are not considered "kernel" (like providing data for a marketing site), a generic mechanism to differentiate those uses cases will be built, and proper Python and REST APIs will be provided, to different taxonomies/tags for the same content. Rejected Alternatives