Questions from @Milimetric during grooming:

What is left in eventlogging after this move?
@phuedx are you thinking about this work towards decommissioning or a bigger plan for eventlogging?

Event platform is a way to publish events to a stream agnostically, open question about whether or not this creates a duplication of effort between MP and EP. Let's discuss!

CC @Ottomata

Event platform is a way to publish events to a stream agnostically, open question about whether or not this creates a duplication of effort between MP and EP. Let's discuss!

EventLogging, MetricsPlatform and EventBus are all (more or less) 'opinionated' Event Platform clients.

I started writing a whole comment about how it could be nice to have a shared composer-required PHP EventGate producer library, but on second thought I'm not sure how useful that would be. The EventGate HTTP API is pretty simple.

A shared PHP library that tied together EventStreamConfig and EventGate producing could be nice. We could use the same config 'EventGate client' instance for EventBus and EventLogging and MetricsPlatform then.

But, that might be out of scope of this project ;)

For JS, I don't think we have many use cases other than MW analytics. I'm not sure if a shared JS eventgate producer library would be that helpful.

See also: https://wikitech.wikimedia.org/wiki/Event_Platform/Producer_Requirements
(When using EventGate, many of those requirements are handled by EventGate)

FWIW, I think Data Products should own the EventLogging extension and do whatever they think is best.

The trickiest part about making big changes to it could be '3rd party' support, which I've heard is a thing, but don't know anything about.

In T367034#9876129, @Ottomata wrote:

FWIW, I think Data Products should own the EventLogging extension and do whatever they think is best.

Interesting… /cc @WDoranWMF

The trickiest part about making big changes to it could be '3rd party' support, which I've heard is a thing, but don't know anything about.

For sure. FWIW MediaWiki extensions aren't in scope for the Stable Interface Policy BUT we tend to follow it for EventLogging. It might be worth formally deciding whether or not to and announcing it 🤔 Unfortunately, Pingback doesn't include extensions and WikiApiary appears to be down so it's difficult for us to determine how many third-parties are using EventLogging.

In T367034#9875802, @VirginiaPoundstone wrote:

What is left in eventlogging after this move?

1. [PHP] Pre-draft-03 JSONSchema validation code (see T317793: [EPIC] Deprecate EventLogging::schemaValidate())
2. [JS] The mw.eventLog.Schema class, which overlaps with Metrics Platform a little and has been around for _a long time_ (see T305491: Deprecate/delete the mw.eventLog.Schema class)
3. [JS] The mw.eventLog.logEvent() method (see T317874: [EPIC] Deprecate mw.eventLog.logEvent())
4. [PHP] The EventLogging::logEvent() method (see T318263: [EPIC] Deprecate EventLogging::logEvent())
5. [PHP] The EventLogging::submit() method, which we should keep!

@phuedx are you thinking about this work towards decommissioning or a bigger plan for eventlogging?

I would like to see 1 through 4 Done™.

I have have a feeling that Timo will have objections about 1.-4. These are ones possibly used by 3rd parties?

Non-blocking technical debt, tidy up part of EventLogging. Moving to backlog.

Change #1227747 had a related patch set uploaded (by Phuedx; author: Phuedx):

[mediawiki/extensions/TestKitchen@master] PHP SDK: Merge Wikimedia\MetricsPlatform library

https://gerrit.wikimedia.org/r/1227747