Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: [FC-0074] add naming suggestions to use when creating new events #467

Merged
merged 1 commit into from
Feb 18, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/how-tos/create-a-new-event.rst
Original file line number Diff line number Diff line change
Expand Up @@ -186,7 +186,7 @@ The :term:`Event Definition` should be implemented in the corresponding subdomai

- The event definition should be documented using in-line documentation with at least ``event_type``, ``event_name``, ``event_description``, and ``event_data``. This will help consumers understand the event and react to it. See :doc:`../reference/in-line-code-annotations-for-an-event` for more information.
- The :term:`Event Type` should be unique and follow the naming convention for event types specified in the :doc:`../decisions/0002-events-naming-and-versioning` ADR. This is used by consumers to identify the event.
- The ``event_name`` should be a constant that is used to identify the event in the code.
- The ``event_name`` should be a constant that is used to identify the event in the code. See :doc:`../reference/naming-suggestions` for more information on naming events.
- The ``event_description`` should describe what the event is about and why it is triggered.
- The ``event_data`` should be the payload class that is used to define the data that is included in the event.
- The ``data`` dictionary should contain the payload class that is used to define the data that is included in the event. This will help consumers understand the event and react to it. Try using a descriptive name for the data field, but keep consistency with the payload class name. Avoid using suffixes like ``_data`` or ``_payload`` in the data field name.
Expand Down
1 change: 1 addition & 0 deletions docs/reference/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -14,3 +14,4 @@ References
oeps
architecture-subdomains
real-life-use-cases
naming-suggestions
10 changes: 10 additions & 0 deletions docs/reference/naming-suggestions.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
Naming Suggestions for Open edX Events
########################################

When naming a new event and contributing it back to this repository, consider the following suggestions:

- Use a name that is descriptive to the event's purpose. For example, the event associated with a user's enrollment in a course is named ``COURSE_ENROLLMENT_CREATED``, which clearly indicates the event's purpose.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think the name should always have a verb in it? Generally would it always be a verb in past tense eg created, enrolled, succeeded, failed?

Copy link
Member Author

@mariajgrimaldi mariajgrimaldi Feb 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this commit I specified where this standard we've enforced so far comes from: 34562b1. So yes, according to the naming and versioning ADR, those are the usual verbs that are used for the event type string when following OEP-41.

- Use a name that is unique within the framework.
- Match the name to the ``event_type`` identifier. For example, the ``COURSE_ENROLLMENT_CREATED`` event has an ``event_type`` of ``org.openedx.learning.course.enrollment.created.v1``. You can use the ``event_type`` as a reference when naming the event. See :doc:`../decisions/0002-events-naming-and-versioning` for more information on naming and versioning events.
- Avoid using ``event`` in the name. It is implied that the variable is an event, so there is no need to include it in the name.
- Try reviewing the :doc:`existing events <../reference/events>` in the repository to ensure that the name you choose is unique and follows the naming conventions.