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

[mediawiki/extensions/MetricsPlatform@master] Expose experiment enrollment sampling method

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

Change #1211069 merged by jenkins-bot:

[mediawiki/extensions/MetricsPlatform@master] Expose experiment enrollment sampling method

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

Could you elaborate on the string $identifier parameter? In the test I can see $identifier = '0x0ff1c3'; but I don't know which are the responsibilities/assumptions callers should take care. The first surprise is the type string as my current shallow understanding is we'd prefer to work with MW user local or central IDs.

In T410896#11454373, @Sgs wrote:

Could you elaborate on the string $identifier parameter? In the test I can see $identifier = '0x0ff1c3'; but I don't know which are the responsibilities/assumptions callers should take care. The first surprise is the type string as my current shallow understanding is we'd prefer to work with MW user local or central IDs.

Currently, when we're enrolling based on user ID, we convert that ID to a string, salt it with the experiment name, hash it, and convert that hash to a number between 0 and 1. I pushed this detail (that the user ID is converted to a string) to the API. I did so because we're looking to support experiments on search sessions, which use a string as an identifier.

Perhaps it's too general and we could provide a narrower API on top of it, e.g.

namespace MediaWiki\Extension\MetricsPlatform\XLab;

interface Coordinator {
  public function getEnrollmentForUser( UserIdentity $user, string $experimentName ): ?string;
}

In T410896#11456749, @phuedx wrote:

In T410896#11454373, @Sgs wrote:

Could you elaborate on the string $identifier parameter? In the test I can see $identifier = '0x0ff1c3'; but I don't know which are the responsibilities/assumptions callers should take care. The first surprise is the type string as my current shallow understanding is we'd prefer to work with MW user local or central IDs.

Currently, when we're enrolling based on user ID, we convert that ID to a string, salt it with the experiment name, hash it, and convert that hash to a number between 0 and 1. I pushed this detail (that the user ID is converted to a string) to the API. I did so because we're looking to support experiments on search sessions, which use a string as an identifier.

Perhaps it's too general and we could provide a narrower API on top of it, e.g.

namespace MediaWiki\Extension\MetricsPlatform\XLab;

interface Coordinator {
  public function getEnrollmentForUser( UserIdentity $user, string $experimentName ): ?string;
}

I would rather consume an API that uses UserIdentity than a string identifier. However, I'm still confused and missing a complete example of enrollment with this API. How does this help with the account creation problem? It feels the ad-hoc re-enrollment for logged-in active experiments is still necessary, isn't it? Here's a PoC GrowthExperiments/+/1219179 that tries to get rid of the account creation override problem. Review feedback is appreciated, maybe I'm getting something wrong.

In T410896#11469599, @Sgs wrote:
I would rather consume an API that uses UserIdentity than a string identifier. However, I'm still confused and missing a complete example of enrollment with this API. How does this help with the account creation problem? It feels the ad-hoc re-enrollment for logged-in active experiments is still necessary, isn't it? Here's a PoC GrowthExperiments/+/1219179 that tries to get rid of the account creation override problem. Review feedback is appreciated, maybe I'm getting something wrong.

Not 100% sure if this function will help you with that problem. getEnrollmentForUsers is not changing the way the enrollment is happening. In fact no change is made when you call it. It's only providing information about in which group will be (or has been) enrolled the current user. The idea behind this is that developers can know that group even when the ExperimentManager is not being initialized and I guess that also before the enrollment itself in a context where the enrollment will happen at some point.

I'm not very familiar with the problem you have mentioned but I remember something about that your extension don't know yet the user when the enrollment is happening and you have to re-run it again once you know that user identifier. Is that right? In that case I guess that this function won't help you because you will be able to know the group based on the user but you are still needing that user identifier at the right moment. This functions is not affecting how the enrollment itself is running

In T410896#11469599, @Sgs wrote:

However, I'm still confused and missing a complete example of enrollment with this API. How does this help with the account creation problem?

Sorry, @Sgs. This was confusion on my part. The account creation problem that you speak of – that you have to re-enroll (including reinitialising the $wgMetricsPlatformUserExperiments config var, etc.) users during the LocalUserCreated hook – should be solved in part by T413983: Expose Experiment Re-enrollment method.