Change #1248815 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] New column for references delta in ce_event_contributions

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

Change #1248820 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add referencesDelta to persistence layer

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

Change #1248851 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Compute referencesDelta in EventContributionComputeMetrics

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

Change #1249904 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add progress bar to contributions tab in event detials

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

@cmelo, now that we have the editors view being released soon, does this work also cover references in the editor view? Or should that be a separate ticket?

In T411681#11699029, @ifried wrote:

@cmelo, now that we have the editors view being released soon, does this work also cover references in the editor view? Or should that be a separate ticket?

Hi @ifried I think we can use this task, since the title says "in the contribution tab", I was already thinking of doing it.

Great, thank you, @cmelo!

Change #1259972 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add references to summary

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

Change #1261373 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add references column to Edits view contributions table

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

Change #1261383 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add references column to Editors view contributions table

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

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://ab03eefa0e.catalyst.wmcloud.org/w/

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

https://ab03eefa0e.catalyst.wmcloud.org/w/

Hi @ifried, there is a question in code review:

This value makes it impossible to distinguish between events where the references delta is actually 0, and those from before we introduced this feature. This is not necessarily a problem, but needs to be considered both from a user perspective, and when making graphs/reports/statistics on event data. There's also the question of whether we would want to backfill this column (which I assume we don't, but it's one of many thing that the AC don't mention explicitly).

Right now, using 0 as the default makes two different cases look the same:

events that actually have a delta of 0
events created before this feature existed

Would it be better to use NULL as the default instead?
That way:

NULL = no data (old events)
0 = real value

Or do you think keeping 0 is fine?

More than 0 vs null, I think my question would be: what do we do with existing events? The three options being:

• Treat them as not having a reference delta defined (so, not shown in the UI, not included in reports, etc)
  • Pros: clear distinction.
  • Cons: special-casing that will remain around "forever"
• Treat them as having a reference delta of 0 (regardless of the real delta)
  • Pros: trivial implementation
  • Cons: inaccurate data
• Retroactively compute a reference delta for them
  • Pros: no special-casing; accurate data
  • Cons: more work than the other two

Let's do option 1 (don't show references data for older events)

Decision

After reviewing all scenarios, we agreed on the following approach:

We will display all data as it exists at the time.

Behavior

• Once the new data point becomes available, it will be shown for all events.
• Initially, the value will appear as 0.
• As soon as a reference is added or removed, it will be tracked and reflected in the event data.

Implications

This may lead to situations such as:

• In an ongoing event, User A added references before this data point existed → not tracked.
• User B added references after the data point was introduced → tracked and displayed.

As a result, event contribution data may only partially reflect earlier activity.

Communication

• This behavior will be clearly communicated to users in the feature release announcement.

Technical Note

• Given this approach, the ce_event_contributions field will use a default value of 0.
• A NULL default is not required.

In T411681#11815856, @cmelo wrote:

• Given this approach, the ce_event_contributions field will use a default value of 0.
• A NULL default is not required.

I do still think it should have a NULL default. Partly because that's what NULL is for (a data point that doesn't exist, as opposed to a data point that exists and with an actual falsey value); and partly because it would still let us distinguish the old rows going forwards, should the need arise (e.g. in statistics, or if we ever were to actually implement versioning).

Other than that I believe we are all on the same page now!

In T411681#11815902, @Daimona wrote:

In T411681#11815856, @cmelo wrote:

• Given this approach, the ce_event_contributions field will use a default value of 0.
• A NULL default is not required.

I do still think it should have a NULL default. Partly because that's what NULL is for (a data point that doesn't exist, as opposed to a data point that exists and with an actual falsey value); and partly because it would still let us distinguish the old rows going forwards, should the need arise (e.g. in statistics, or if we ever were to actually implement versioning).

Other than that I believe we are all on the same page now!

Yes, agree, will change it.

Change #1248820 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add referencesDelta to persistence and entity layers.

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

After asking about it on #mediawiki-content-plataform, they said:
RevisionRenderer is completely uncached, and so shouldn't really be used directly. RevisionRenderer is used by ParserOutputAccess, which is the main cached entry point to parser content.  So yes, that is the entry point you should use.

We need to:

1 - Create a patch to change the use of RevisionRenderer to use ParserOutputAccess for the "links", then rebase the add references patch on the top of it and for the "references" also use ParserOutputAccess.