docs: [FC-0074] use glossary as reference material

docs/how-tos/create-new-filter.rst

@@ -20,6 +20,8 @@ Assumptions
 * You have a basic understanding of Python and Django.
 * You understand the concept of filters or have reviewed the relevant
   :doc:`/concepts/index` docs.
+* You are familiar with the terminology used in the project, such as
+  :term:`filter type<Filter Type>`, :term:`filter signature<Filter Signature>`, etc. If not, you can review the :doc:`/reference/glossary` docs.
 
 Steps
 *****
@@ -34,10 +36,10 @@ Steps
 
 #. Place your filter in an architecture subdomain
 
-    As specified in the Architectural Decisions Record (ADR) filter naming and versioning, the filter definition needs an Open edX Architecture
+    As specified in the Architectural Decisions Record (ADR) filter naming and versioning, the :term:`filter definition<Filter Definition>` needs an Open edX Architecture
     Subdomain for:
 
-    - The type of the filter: ``{Reverse DNS}.{Architecture Subdomain}.{Subject}.{Action}.{Major Version}``
+    - The :term:`type of the filter<Filter Type>`: ``{Reverse DNS}.{Architecture Subdomain}.{Subject}.{Action}.{Major Version}``
     - The package name where the definition will live, eg. ``learning/``.
 
     For those reasons, after studying your new filter purpose, you must place it in one of the subdomains already in use, or introduce a new subdomain:
@@ -57,28 +59,28 @@ Steps
 
     Defining the filter's behavior includes:
 
-    - Defining the filter type for identification
-    - Defining the filter's signature
+    - Defining the :term:`filter type<Filter Type>` for identification
+    - Defining the :term:`filter signature<Filter Signature>`
     - Defining the filter's behavior for stopping the process in which it is being used
 
-    The filter type is the name that will be used to identify the filter's and it'd help others identifying its purpose. For example, if you're creating a filter that will be used during the student registration process in the LMS,
-    according to the documentation, the filter type is defined as follows:
+    The :term:`filter type<Filter Type>` is the name that will be used to identify the filter's and it'd help others identifying its purpose. For example, if you're creating a filter that will be used during the student registration process in the LMS,
+    according to the documentation, the :term:`filter type<Filter Type>` is defined as follows:
 
     ``{Reverse DNS}.{Architecture Subdomain}.student.registration.requested.{Major Version}``
 
     Where ``student`` is the subject and ``registration.requested`` the action being performed. The major version is the version of the filter, which will be incremented
     when a change is made to the filter that is not backwards compatible, as explained in the ADR.
 
-    Now that you have the filter type, you'll need to define the filter's signature and overall behavior. The filter's signature, which is the set of parameters that the filter will manipulate, depends on where the filter is located. For example,
-    if you're creating a filter that will be used during the student registration process in the LMS, the filter's signature will be the set of parameters available for that time for the user. In this case, the filter's signature will be the set of parameters that the registration form sends to the LMS.
+    Now that you have the :term:`filter type<Filter Type>`, you'll need to define the :term:`filter signature<Filter Signature>` and overall behavior. The :term:`filter signature<Filter Signature>`, which is the set of parameters that the filter will manipulate, depends on where the filter is located. For example,
+    if you're creating a filter that will be used during the student registration process in the LMS, the :term:`filter signature<Filter Signature>` will be the set of parameters available for that time for the user. In this case, the :term:`filter signature<Filter Signature>` will be the set of parameters that the registration form sends to the LMS.
 
     You can ask yourself the following questions to help you figure out your filter's parameters:
 
     - What is the filter's purpose? (e.g. to validate the student's email address)
     - What parameters will the filter need to to that? (e.g. the email address)
     - Where in the registration process will the filter be used? (e.g. after the student submits the registration form but before anything else)
 
-    With that information, you can define the filter's signature:
+    With that information, you can define the :term:`filter signature<Filter Signature>`:
 
     - Arguments: ``email``. Since we want this filter to be broadly used, we'll add as much relevant information as possible for the user at that point. As we mentioned above, we can send more information stored in the registration form like ``name`` or ``username``.
     - Returns: since filters take in a set of parameters and return a set of parameters, we'll return the same set of parameters that we received.
@@ -126,8 +128,8 @@ Steps
 
     Some things to note:
 
-    - The filter's type is defined in the ``filter_type`` class attribute. In this case, the filter type is ``org.openedx.learning.student.registration.requested.v1``.
-    - The filter's signature is defined in the ``run_filter`` method. In this case, the signature is the ``form_data`` parameter.
+    - The filter's type is defined in the ``filter_type`` class attribute. In this case, the :term:`filter type<Filter Type>` is ``org.openedx.learning.student.registration.requested.v1``.
+    - The :term:`filter signature<Filter Signature>` is defined in the ``run_filter`` method. In this case, the signature is the ``form_data`` parameter.
     - The ``run_filter`` is a class method that returns the same set of parameters that it receives.
     - The ``run_filter`` class method calls the ``run_pipeline`` method, which is the method that executes the filter's logic. This method is defined in the ``OpenEdxPublicFilter`` class, which is the base class for all the filters in the library. This method returns a dictionary with the following structure:
 
@@ -148,7 +150,7 @@ Steps
         "form_data": form_data,
       }
 
-    Where ``form_data`` is the same set of parameters that the filter receives, which is the accumulated output for the filter's pipeline. That is how ``run_filter`` should always look like.
+    Where ``form_data`` is the same set of parameters that the filter receives, which is the accumulated output for the :term:`filter pipeline<Filter Pipeline>`. That is how ``run_filter`` should always look like.
     - The filter's behavior for stopping the process is defined in the ``PreventRegistration`` exception which inherits from the ``OpenEdxFilterException`` base exception. In this case, the exception is raised when the filter stops the registration process. This is done in the service where the filter is being used, which in this case is the LMS.
     - The class name is the filter's type ``{Subject}.{Action}`` part in a camel case format. In this case, the filter's name is ``StudentRegistrationRequested``.
 
@@ -196,7 +198,7 @@ Steps
         self.assertDictContainsSubset(attributes, exception.__dict__)
 
 .. note::
-    Basically, we're testing the filter's signature and the filter's behavior for stopping the process. The first test is testing the filter's signature, which is the set of parameters that the filter receives and returns. The second test is testing the filter's behavior for stopping the process, which is the exception that is raised when the filter stops the process.
+    Basically, we're testing the :term:`filter signature<Filter Signature>` and the filter's behavior for stopping the process. The first test is testing the :term:`filter signature<Filter Signature>`, which is the set of parameters that the filter receives and returns. The second test is testing the filter's behavior for stopping the process, which is the exception that is raised when the filter stops the process.
 
 .. .. seealso::
 

docs/how-tos/using-filters.rst

@@ -2,7 +2,7 @@ How to use Open edX Filters
 ---------------------------
 
 Using openedx-filters in your code is very straight forward. We can consider the
-various use cases: implementing pipeline steps, attaching/hooking pipelines to filter,
+various use cases: implementing :term:`Pipeline Steps<Pipeline Steps>`, attaching/hooking pipelines to filter,
 and triggering a filter. We'll also cover how to test the filters you create in your service.
 
 
@@ -11,8 +11,8 @@ Implement pipeline steps
 
 Let's say you want to consult student's information with a third party service
 before generating the students certificate. This is a common use case for filters,
-where the functions part of the filter's pipeline will perform the consulting tasks and
-decide the execution flow for the application. These functions are the pipeline steps,
+where the functions part of the :term:`filter pipeline<Filter Pipeline>` will perform the consulting tasks and
+decide the execution flow for the application. These functions are the :term:`pipeline steps<Pipeline Steps>`,
 and can be implemented in an installable Python library:
 
 .. code-block:: python
@@ -83,8 +83,8 @@ There's two key components to the implementation:
 Attach/hook pipeline to filter
 ******************************
 
-After implementing the pipeline steps, we have to tell the certificate creation
-filter to execute our pipeline.
+After implementing the :term:`pipeline steps<Pipeline Steps>`, we have to tell the certificate creation
+filter to execute our :term:`pipeline<Filter Pipeline>`.
 
 .. code-block:: python
 

docs/reference/django-plugins-and-filters.rst

@@ -37,5 +37,5 @@ file. The dictionary has the following structure:
 Create pipeline steps
 *********************
 
-In your own plugin, you can create your own pipeline steps by inheriting from ``PipelineStep`` and implementing the
-``run_filter`` method. You can find examples of pipeline steps in the ``openedx-filters-samples`` repository. See :doc:`/quickstarts/index` for more details.
+In your own plugin, you can create your own :term:`pipeline steps<Pipeline Steps>` by inheriting from ``PipelineStep`` and implementing the
+``run_filter`` method. You can find examples of :term:`pipeline steps<Pipeline Steps>` in the ``openedx-filters-samples`` repository. See :doc:`/quickstarts/index` for more details.

docs/reference/glossary.rst

@@ -0,0 +1,27 @@
+Open edX Filters Glossary
+##########################
+
+A filter has multiple components that are used to define, execute and handle filters, such as pipeline, pipeline steps, filter definition, filter signature, filter type, filter exceptions, filter configuration, etc.  This glossary provides definitions for some of the terms to ease the adoption of the Open edX Filters library.
+
+.. glossary::
+
+   Pipeline
+     A pipeline is a list of functions executed in a specific order; these functions are known as pipeline steps. Each function in the pipeline takes the output of the previous function as its input, with the final function's output serving as the overall output of the filter. These pipelines are configured in the filter configuration and are executed in sequence.
+
+   Pipeline Step
+     A pipeline step is a function within a pipeline that receives, processes, and returns data. Each step may perform operations like transforming, validating, filtering, or enriching data. Pipeline steps are implemented as classes that inherit from a base step class and define specific logic within their ``run_filter`` method, which conforms to the filter's signature.
+
+   Filter Definition
+     A filter definition is the class that defines the ``run_filter`` method for a filter, specifying the input and output behavior. This class, which inherits from a standard filter base, executes the configured pipeline steps, enabling custom processing within the defined filter.
+
+   Filter Signature
+     The filter signature consists of the specific parameters required by a filter's ``run_filter`` method. It defines the expected input and output structure for the filter, detailing the data the filter will process.
+
+   Filter Type
+     The filter type is a unique identifier for the filter, following a standardized format (e.g., reverse DNS style). This type is used as an index for configuring the filter pipeline and specifies which configuration settings apply to a given filter.
+
+   Filter Exceptions
+     Filters can raise exceptions to control the flow of the pipeline. If a filter raises an exception, the pipeline halts, and the exception becomes the pipeline's output. Exceptions are typically raised when certain conditions specified in the filter's logic are met, signaling an event or state change.
+
+   Filter Configuration
+     Filter configuration is a dictionary that defines the pipeline settings for a filter. Each filter type has its own configuration, which includes settings like whether errors should fail silently or propagate, and the sequence of pipeline steps. Configurations specify the filter type, error-handling preferences, and a list of module paths for each pipeline step to be executed.

docs/reference/index.rst

@@ -5,5 +5,6 @@ References
    :maxdepth: 1
    :caption: Contents:
 
+   glossary
    filters
    django-plugins-and-filters