User:Ostrzyciel/GSoC 2020/week 16
These were the last two weeks of the internship, so I tried to wrap everything up as much as possible. It looks like I won't finish everything that was planned, but the plan was quite ambitious from the start. Over the course of the internship I have also stumbled upon many issues that we have not foreseen when scheduling the work, so overall I think I put a bit more effort in the project than planned. I will be finishing the work that I've started in the coming months.
Finished work
[edit]Directly related to the project
[edit]- Introduce the EditResult class and pass it to extensions. This object encapsulates information about the effects of the edit in the context of the page, for example whether the edit was a revert and which edits were reverted. It simplifies greatly revert detection for extensions.
- Choose the definition of a "reverted" edit. Decided on revert detection method to be used in the project.
- Detect manual reverts and mark them with mw-manual-revert tag. The biggest feature I've managed to finish. Based on the comments, I think wikipedians mostly like it.
- Fix handling of multi-edit undos. Up until now it was impossible to inform extensions about multi-edit undos, as EditPage lacked code that would properly track all required parameters. That is fixed now, the patch also introduced a few integration tests that ensure undos are detected properly in all cases.
- Make EditResult serializable. This is used to store it the DB for later possible use. It will be also used to serialize RevertedTagUpdateJob.
- Save the serialized EditResult in ct_params field of revert tags. This information can be later retrieved for analytics purposes. It can also be used to schedule a delayed RevertedTagUpdateJob.
- Fix handling of null edits in PageUpdater. This was discovered due to a production issue with duplicate notification emails that affected pretty much all WMF wikis. The issue was… bad, but we managed to fix it quickly once we identified it.
- Don't mark "dirty" undos with the mw-undo tag. This is to prevent users from marking arbitrary edits as undos. It is mostly in preparation for the reverted tag.
Extras
[edit]- Add getRevisionIdsBetween method to RevisionStore. This method is to be used by core and various extensions that want to determine which revisions were reverted, given the newest and oldest reverted revisions.
- Add INCLUDE_* constants in RevisionStore. This is a minor extra to clean up the use of 'include_*' options in various get*Between methods.
- Indicate reverts in EventBus data. Now the Product Analytics team can fully use all information about reverts provided by the new EditResult object. The task involved modifying the appropriate event schema and writing code for filling it with information.
(Yet) unfinished work
[edit]- The reverted tag. It's mostly finished, but still in code review. This is the main feature that I was supposed to implement, but it turned to be really hard to implement properly. When I started implementing it, I tried to imagine as many ways to abuse it as possible and there turned out to be quite a lot. I have… some experience with wiki communities and I know that there are always people who want to abuse wiki's mechanisms to prove their point or to wage "wars" on other users. I really wouldn't want to see people using it this way, so I came up with a number of mitigations that are supposed to minimize the abuse potential of it. These mechanisms are quite complex (see this task for details) and reviewing that is equally as hard, so this particular feature being a bit late doesn't surprise me a lot.
- Integrating the reverted tag with FlaggedRevs. There is a new revert approval mechanism introduced by the reverted tag that extensions can hook into. FlaggedRevs is a content management extension used on Wikimedia wikis that have their code updated weekly, so FlaggedRevs should be the first extension we integrate with. The commit is mostly ready, it just needs CR.
- The maintenance script for filling the manual revert and reverted tags. This is an extra feature that I have proposed to implement as it's something that I would personally gladly use on my wiki. I started implementing it, but then I came up with all the issues revolving around the reverted tag, so I had to temporarily put this on hold until I finish the reverted tag. I will come back to this task later for sure, I think it should be shipped in 1.36 with the reverted tag to make the new feature "complete".
- Write documentation on mediawiki.org. It's mostly finished and I'll be submitting it soon. Some parts of it have to wait for the features to be completed, though.
- Deprecate RollbackComplete hook. This is a minor thing to do, the hook is now redundant with PageSaveComplete providing all necessary information to extensions. The patch is in code review.
Other things I may work on later
[edit]- Echo integration. The notification system currently uses a complex revert detection system that is now largely redundant. That needs to be cleaned up. ProcrastinatingReader has started working on this, but I will probably try to help him a bit later.
- FlaggedRevs improvements. When Echo starts using the new EditResult-based revert detection, we will be able to remove Echo-specific code in FlaggedRevs. Besides that, FlaggedRevs currently does not mark its rejects as undos properly. With the improvements I made to EditPage it should be now possible for FlaggedRevs to do that.
- Integrating the reverted tag with Approved Revs and possibly Moderation. I will have to look into both of these extensions carefully and I'll probably suggest some patches to integrate them properly with the reverted tag feature.
Summary
[edit]Overall, I'm quite satisfied with this internship. The project turned out to be interesting and I will gladly continue it in my spare time later. I didn't manage to finish it in time, but given how much work it ended up involving, I'm not surprised at all. I have definitely learned a lot – huge thanks to all reviewers of my code and my mentors, who were very helpful and gave me numerous hints. This project also affects many wikis in a significant way and it's quite satisfying to work on something that will be used by many.
I only regret that my initial proposal for GSoC was not accepted (it was about making InstantCommons faster) and I won't have another shot at trying it again, as I'm finishing my degree in a year. I will probably do it anyway, someday.
Ostrzyciel (talk) 13:36, 26 August 2020 (UTC)