0001 Purpose of This Repo#

Status#

Accepted

Context#

We want to issue the certificates and badges for students participating in the courses.

The present workflow used for the certificates is quite complex because we generate them based on the data pulled from the Open edX databases (MySQL and MongoDB). The purpose of this repository is to implement a service closely connected with Open edX.

We want to support the following certificate types:

  1. Certificate of achievement

    We grant it when a student receives a passing grade in both of the following:

    1. Course assignments (excluding the final exam).

    2. The final exam.

  2. Certificate of completion

    We grant it when a student receives the required percentage of the completion checkmarks in the course.

  3. Badge of achievement/completion (temporary name)

    Almost identical to the certificates of achievement/completion. The only difference is that we award them for completing Lessons.

  4. Pathway certificate

    We grant it when a student receives a passing grade in all courses/lessons in the Pathway.

  5. Achievement (temporary name)

    Similar to the Badges, recently removed from Open edX. Example criteria:

    1. A student received a passing grade on the course assignments (excluding the final exam).

    2. A student received a passing grade on the final exam.

    3. A student received all completion checkmarks in the course.

    4. A student has posted a comment in the forum.

Other notes:

  1. We do not need to pull data in real time. This service can retrieve data periodically, but the frequency should be configurable per course.

  2. We need to design an interface for configuring these certificates per course. The goal is to make it as simple as possible for the course authors. It will be designed in a future iteration.

Decision#

  1. We will implement the certificates mechanism as a Django app plugin.

  2. This plugin will be installed on the same server as the Open edX instance. It will use the same database as the Open edX instance to optimize the performance. This decision is made to minimize the latency that would be introduced by querying web APIs.

  3. The goal is to rely only on the public Python APIs and avoid direct access to the database or models. This is to minimize breaking changes in the next Open edX releases.

  4. The details of this plugin’s architecture are described in the 0002 Architecture document.

Consequences#

We will stop using the built-in certificates mechanism. The goal of this repository is to have as little dependencies from the core edx-platform as possible to make it easier to maintain and upgrade.

Rejected Alternatives#

We considered:

  1. Using the certificates built into Open edX.

    However, we need to rework them significantly to meet the described requirements. Given the plans to migrate the course certificates to the credentials service, maintaining this approach could take a lot of work.

  2. Using the credentials service.

    Currently, this service supports only Programs. It means that it is tightly coupled to the course-discovery IDA. We will use Pathway instead of Programs to remove this dependency and gain more flexibility. Therefore, the credentials service would also require significant reworks to support the necessary features.

  3. Using the existing implementation of the Badges.

    This code was not maintained for a long time and was recently removed from Open edX.

Definitions#

  1. Course

    A standard Open edX course. Also referred to as a Course XBlock or a CourseBlock.

  2. Lesson

    A course that consists of a single section. The section-to-course extension extracts this section from a “full” course.

  3. Pathway

    A similar concept to Open edX Programs but handled by an Open edX plugin. Once we complete the Pathway planning phase, we will update this definition and add a link.