AprilSylph
feat(PostBlock): Implement New XKit migration
Description
#1279 but for PostBlock.
Along with https://github.com/new-xkit/XKit/pull/2182, this implements a button that migrates PostBlock data from New XKit to XKit Rewritten when pressed. It communicates via custom events from one extension's content script to the other.
Testing steps
- Load the corresponding New XKit PR (one can check out the branch before installing PostBlock or can force update PostBlock).
- Use New XKit to block at least one post.
- Enable PostBlock in XKit Rewritten.
- Press the button in the New XKit PostBlock settings pane and confirm the migration.
- Unblock the post in New XKit. Refresh the page. (Apparently we never added cleanup to XKit 7 PostBlock, whee).
- Confirm that the post is hidden, and that it appears again when the last entry is removed from XKit Rewritten PostBlock.
¯\_(ツ)_/¯ We do still have users with New XKit access on Firefox, but obviously many users who would want to migrate have already lost access. Nonzero but low amount of utility; I don't know how to weigh that against review effort.
Hmm, yeah, I think it's not worth it. Given the limited impact on the user experience of not doing this (needing to re-block a previously-blocked post if it comes across one's dashboard) and the now much more limited demographic of who can be saved from that, I would rather focus on other things.
...In this situation, would you prefer me to just take myself off the reviewers list, or outright close the PR? (Maybe the latter should be reserved for the more severe situation of "I the project author think this should not happen"? To be clear, this situation is just "I think my finite capacity for volunteer work would be better spent on other things". You could theoretically still get a review from a different collaborator.)
I wouldn't make said per-user impact argument, but the user numbers are likely low, yeah, particularly because if we don't make a public post about a hypothetical implementation of both sides of this migration path its discoverability is essentially zero, and it makes little sense to make said public post at this point.
...In this situation, would you prefer me to just take myself off the reviewers list, or outright close the PR?
From a general philosophical standpoint, I do kind of get "we actively don't want that" vibes from "the reviewer closed the PR," and like, in theory once could decide to review both sides, I guess. In this particular case I don't think it really matters either way.
I've sort of gone back and forth about how much I feel like cleaning up the open PR list "matters"; I sort of figured that if I saw the non-draft number start going down I would take a pass at closing out the rest, because maybe having a low number would feel good or whatever. But then maybe having one fewer feels better whatever the total number is? (I'm aware that the amount of time I spend speculatively psychoanalyzing my project collaborators being any more than "zero time" is probably kind of odd, but fear not, I don't to my knowledge make actual decisions based on it, it's just an idle pastime; I am realizing now that that doesn't actually sound reassuring like I thought it was going to; um, anyway.)
if we don't make a public post about a hypothetical implementation of both sides of this migration path its discoverability is essentially zero, and it makes little sense to make said public post at this point.
Somehow it never occurred to me that this is also the case. This is much more reasonable than my per-user impact argument...
in theory once could decide to review both sides, I guess
It turns out he's actually not a collaborator here yet! I'm going to invite him just because I also thought this statement was true until I checked.
I'm aware that the amount of time I spend speculatively psychoanalyzing my project collaborators being any more than "zero time" is probably kind of odd
Well, if you ever figure out what is wrong with me and how I can change that, please do tell 😄