After migrating this Q&A from Crypto.SE to Security.SE, I accidently noticed a bug/glitch related to migrated Q&As. Practically, this glitch - which needs either a bugfix or an explanation related to the logic behind it - allows to skew reputation across SE sites.
Since this bug/glitch is related to the SE core functionality, it can only be fixed by the SE dev team.
Reproducing the bug
- Vote for a question and/or answer at an SE site.
- Assume the question gets migrated to another SE site
- You can now vote the same question and answer(s) again, even though you already voted on them at the original site.
This boils down to "the ability to double-vote migrated Q&As".
Something tells me this isn't the way it should work, since it skews reputation for the involved users and opens the door to cheating, as it gives the posting users of such Q&As an unfair advantage even though their Q was clearly "off-topic" at the originating site.
How to fix it quick and easy
Fixing this bug is pretty simple: reset all votes when a Q&A is migrated, so that a migrated question and potential answers are at 0 after migration.
This also makes sense, at it would remove the votes/reputation at the originating site, where the Q&A was off-topic; which is the reason for migration in the first place.
From a coding/design point of view, it wouldn't be more complicated or resource hungry as what the SE code already does when a Q&A gets deleted, or merged, or a user account gets removed/deleted...
- At originating site, drop all Q&A-related votes and accordingly recalc reputation of the few users who voted; if any.
- Migrate the (now virgin, zero-votes) Q&A as already implemented.
(aka That moment when a KISS principle voids potential "by design" arguments.)
Here's a coding hint to show there aren't any bottlenecks you might be seeing: Step 1 can be partly cron-jobbed as user reputation recalculation doesn't have to happen instantly.
In a worst case (depending on how messy SE code and DB structures are implemented), the same user would have a cronned rep recalc at two individual sites.
Only the Q&A votes need instant zero-fying/reset using a single, non-complicated DB call before migration (as already implemented) in step 2.
All in all it's pretty simple to fix this glitch. That is, from my personal point of view (speaking as a multi-platform software architect, not as a Crypto.SE mod).
SE has alike code running already. See cron-jobbed rep recalc when "user removed/deleted" and "Q or A deletion". It merely takes some minimal motivation and a tiny bit of glue to copy-and-paste existing code snippets into a bugfix for the whole SE network. (read: "all SE sites" would be fixed with a single bugfix in one of the functions of the SE core that all the - curently 161 - communities run upon.)
Last but not least
As I was able to describe how to fix it while avoiding all resource- and coding-related pitfalls (something that took less than a minute to wrap up in my brain), not fixing the glitch doesn't really seem to make sense.
Therefore... in the unlikely case SE wants to handle this as "not a bug" or "by design", I would definitely appreciate a darn good explanation about the reasoning for this "feature" and any potential logic SE might be seeing... and which I would obviously be missing in that case. One thing is clear: the well-vetted and frequently used arguments going "complicated DB calls with cross-site complications" and/or "coding is difficult" definitely aren't applicable in this case (see my "How to fix it quick and easy" above to grasp why such arguments don't fit in this case).