Change Details

Context: need background information about possible risks, build an insider view of possible risks, and boundaries, can it fail or pass, how much load can it take, which difference could it make, can we inject asynchronous processes, it is hard to estimate some of the risks and feasibility Solution to find more about this: a prototype (the LilDiffCheck) who should work == compare the diff and check if the diff changed and insert the RC log accordingly (== if diff exists then RC inserted), no loss of information is happening through the prototype, no system will break through the existance of the prototype in the system, as prototype it will run in our local environment, storage solution will be defined as we go Even if it is not possible to build the prototype then it is a success because we know now Acceptance criteria [] Issue - recent changes not being written to the database (and/or mention it as an issue for the reviewers) [] Check it's working locally - with no change, seeing that the recent change doesn't get inserted. Ideally, make a video showing it working [] There is a one-line that was added (some other ticket from the updated master) - we need to 'undo' it and leave a comment that it would need to be reconciled with our version [] Have a list of 'still todos' for the reviewers (including the ones above)

Aim: explore the feasibility of comparing the html of the wikipedia page from the cache (if available) before and after reparsing with the wikidata change - via prototype Things to consider: - will it not adversely affect e.g. page loading in production - can we inject asynchronous processes The prototype will: compare the html and check if it changed and insert the RC log accordingly (if diff is 'no change', suppress recent change log) Acceptance criteria [] Issue - recent changes not being written to the database (and/or mention it as an issue for the reviewers) [] Check it's working locally - with no change, seeing that the recent change doesn't get inserted. Ideally, make a video showing it working [] There is a one-line that was added (some other ticket from the updated master) - we need to 'undo' it and leave a comment that it would need to be reconciled with our version [] Have a list of 'still todos' for the reviewers (including the ones above)

Context: need background information about possible risks, build an insider view of possible risks, and boundaries, can it fail or pass, how much load can it take, which difference could it make, can we inject asynchronous processes, it is hard to estimate some of the risks and feasibilityAim: explore the feasibility of comparing the html of the wikipedia page from the cache (if available) before and after reparsing with the wikidata change - via prototype Solution to find more about this: a prototype (the LilDiffCheck) who should work == compare the diff and check if the diff changed and insert the RC log accordingly (== if diff exists then RC inserted), no loss of information is happening through the prototype, no system will break through the existance of the prototype in the system, as prototype it will run in our local environment,Things to consider: - will it not adversely affect e.g. storage solution will be defined as we go Even if it is not possible to build the prototype then it is a success because we know nowpage loading in production - can we inject asynchronous processes The prototype will: compare the html and check if it changed and insert the RC log accordingly (if diff is 'no change', suppress recent change log) Acceptance criteria [] Issue - recent changes not being written to the database (and/or mention it as an issue for the reviewers) [] Check it's working locally - with no change, seeing that the recent change doesn't get inserted. Ideally, make a video showing it working [] There is a one-line that was added (some other ticket from the updated master) - we need to 'undo' it and leave a comment that it would need to be reconciled with our version [] Have a list of 'still todos' for the reviewers (including the ones above)