Experiment

We believe that by comparing Diff before and after reparse we can do reduce the amount of unnecessary RecentChanges notifications

To prove it we will run the prototype to compare Diff before and after reparse and examine the findings

We know we are right if the changes displayed in the RecentChanges page after running a scenario are only related to a change impacting the content of the WP article

Doc where we are compiling the results: https://docs.google.com/document/d/1m8aFxrbZsuqYJlkabvdD9vtnCuo7yE9zcJ-xKcOohZI/edit?tab=t.0

Acceptance Criteria

Engineering testing: (around 1-2 w)

• Check it 'works' for one scenario - test that the change is shown for one example, and contrive an example which would have caused an unnecessary change in the old setup but not in the new (e.g. "if X(wikidata) do nothing")
• Check it works for certain scenarios such as race conditions, preserving priority of local edits, etc

Consultation:

• get a consultation from other engineers of the code/approach. (To add: consider timeouts & therefore user impact being effected the extra diff check & consult engineers)

Results:

• we have a list of pros and cons regarding whether we move forward with this prototype or not, along with a recommendation of either proceed with this or not.

Run scenario

Make a change to the page that would impact the page and see if it comes through
Make a change to the page that would NOT impact the page and see if it comes through

Definition of "done"/"we know enough":

We know we can stop and take a decision when...

• when we tested with at least 1 scenario ----

Summary

• Learning:
• Feasibility score:
• Effort:
• Risks & Mitigations:
  • R: we don't know how to reproduce load in a local environment - M: we could ask other engineers in other teams how they deal with it

Verdict:

Pivot or Persevere?