Guidelines for proactive vs reactive event definitions in openedx-events about openedx-events HOT 3 OPEN

Note: this ticket was advertised in https://discuss.openedx.org/t/guidelines-for-proactive-vs-reactive-event-definitions-in-openedx-events/10661, which may or may not collect its own comments.

from openedx-events.

Back when we had the earliest draft of what eventually became OEP-50 we had a list of possible places in the code where we would want to extend based on common key models of the platform.
You can still find those in the google doc that is linked from oep-50. https://docs.google.com/document/d/1jhnudz6AVtVt0ZSRSwOwj9gJ0lsDDn_8mUCPehLPzLw/edit#heading=h.vo2ywbxdhh5

I think that as long as we are reasonably going to keep them supported for a while the more available events the better. Ideally as an extension or consumer developer I should be able to first look at the list of available events hoping to find that the one I need is already present. Having to include the event in the core first in order to be able to extend it later has two negative consequences IMHO.

• to avoid doing the double work I might be tempted to use a different arquitecture and end up never publishing the event.
• the data passed to the event might be too specific for my current use case. We try to discuss this when the event is being created at this repo, but we might not always catch that.

from openedx-events.

Thanks @felipemontoya. If we were to document your stance and reasoning, we would just need to find a good home for it in the existing docs.

from openedx-events.