Give karma to coauthors #5250

oetherington · 2022-07-12T09:59:20Z

This PR allows users to receive karma from posts that they co-author.

I've tested the following:

Co-authors receive karma when upvoting/lose karma for downvoting (and this can be undone as well)
The karma is shown in their "karma changes" star
The karma is updated correctly when merging accounts

Deploying should require the following process (times are approximate based on local testing and extrapolated for the production DB size):

Run allowMultipleVoteAuthors migration (~10-15 minues)
Deploy code changes (~8 mins)
Run allowMultipleVoteAuthors migration again (<1 min)
Run removeVoteAuthorId migration (~10-15 mins)
Run updateCollectionScores migration (<5 mins)

┆Issue is synchronized with this Asana task by Unito

…legacyKarmaMigration)

Co-authored-by: jpaddison3 <jp@centreforeffectivealtruism.org>

jpaddison3

ASTLAC

Test out the user karma migration as mentioned, read through the comments, then I think you've got it, really nice work.

jpaddison3 · 2022-07-12T21:16:22Z

packages/lesswrong/lib/collections/posts/helpers.ts

+  if (!hasCoauthorPermission) {
+    coauthorStatuses = coauthorStatuses.filter(({ confirmed }) => confirmed);
+  }
+  return coauthorStatuses.map(({ userId }) => userId);


What a cute way to write this

jpaddison3 · 2022-07-12T21:17:01Z

packages/lesswrong/lib/collections/users/helpers.ts

@@ -418,22 +418,6 @@ export const useUserLocation = (currentUser: UsersCurrent|DbUser|null, dontAsk?:
  return {...locationData, setLocationData}
 }

-// utility function for checking how much karma a user is supposed to have
-export const userGetAggregateKarma = async (user: DbUser): Promise<number> => {


Note for onlookers: this was unused.

jpaddison3 · 2022-07-12T21:30:04Z

packages/lesswrong/lib/collections/votes/schema.ts

-    type: String,
+
+  // The IDs of the authors of the document that was voted on
+  authorIds: {


I told you I didn't think this was getting exposed to the GraphQL API. I was wrong. It's conceivable that someone (namely GreaterWrong, see also) is depending on authorId. It seems unlikely, but maybe like 15%? Worth maintaining Author as a resolver-only field, I'd say.

I feel a bit uncomfortable at removing this. It will definitely break some analytics stuff for us, which is probably okay, but I have a feeling it will cause us headaches and that our general paradigm assumes documents have one canonical owner. One example, I assume revisions are still tied to one userId and am not yet sure how this PR will interact with that. (But only partway through reading it)

(I do separately think there's an anti-pattern around having both thing and thing-plural and that the existence of both email and emails has hurt us. (My ideal there is to get rid of the latter).

This is a good point that I hadn't thought of. Whereabouts is it exposed in the API - I still can't find it? (Also, FWIW, a case-insensitive search for authorid in the GreaterWrong codebase returns 0 results).

For now, I'll go ahead and add a resolver-only authorId as this seems to fix the analytics issue (albeit, not beautifully). I feel that this field should generally be considered deprecated though. If there's any reason why you think this won't be enough then let me know and I'll give it a deeper think.

RE documents generally have only one canonical owner: I think this doesn't really matter here as semantically the "owner" of a vote is the userId who cast the vote, not the authors receiving the karma. I definitely could be missing something here though so feel free to object.

jpaddison3 · 2022-07-12T21:38:56Z

packages/lesswrong/server/migrations/2020-09-19-updateCollectionScores.ts

    {
      $group: {
-        _id: '$authorId',
-        karmaTotal: {$sum: "$adjustedPower"},
+        _id: '$authorIds',


I'm not sure if this makes sense anymore.

Unless I'm missing something, I think it's correct. After the $unwind, $authorIds has been exploded into a separate, single string for each user so even though it's still plural it's really only a single ID. I did check the docs to see if there's some way to rename it to $authorId to make it clearer but it looks like that's only possible by adding an extra $project after the $unwind, which doesn't seem worth it performance-wise.

jpaddison3 · 2022-07-12T21:39:23Z

packages/lesswrong/server/migrations/2020-09-19-updateCollectionScores.ts

-            adjustedPower: {$cond: [{$ne: ['$userId', '$authorId']}, '$power', 0]},
-            adjustedAfPower: {$cond: [{$and: [{$ne: ['$userId', '$authorId']}, {$eq: ['$documentIsAf', true]}]}, '$afPower', 0 ]}
+            authorIds: 1,
+            power: 1,


Good refactor

jpaddison3 · 2022-07-12T21:46:04Z

packages/lesswrong/server/migrations/2022-07-07-removeVoteAuthorId.ts

+  action: async () => {
+    await forEachDocumentBatchInCollection({
+      collection: Votes,
+      batchSize: 100,


Suggested change

batchSize: 100,

batchSize: 1000,

jpaddison3 · 2022-07-12T21:47:55Z

packages/lesswrong/server/resolvers/tagResolvers.ts

@@ -233,7 +233,7 @@ async function buildContributorsList(tag: DbTag, version: string|null): Promise<
    // Filtered by: is a self-vote
    { $match: {
      $expr: {
-        $eq: ["$userId", "$authorId"]
+        $eq: ["$userId", "$authorIds"]


Is this fine? I think this is not fine? I think you need to do $in?

If I'm right, careful with your find and replace's

Yeah, you're right - it wasn't find and replace though, just a misunderstanding. It looks like find will happily search the array for a match (like in the rate limiting query you commented on), but the same doesn't work in an aggregation. I've made the change and added a unit test. Mongo's kinda crazy.

jpaddison3 · 2022-07-12T21:52:03Z

packages/lesswrong/server/scripts/mergeAccounts.ts

@@ -111,7 +111,7 @@ Vulcan.mergeAccounts = async (sourceUserId: string, targetUserId: string) => {
  // Transfer votes that target content from source user (authorId)
  // eslint-disable-next-line no-console
  console.log("Transferring votes that target source user")
-  await Votes.rawUpdateMany({authorId: sourceUserId}, {$set: {authorId: targetUserId}}, {multi: true})
+  await Votes.rawUpdateMany({authorIds: sourceUserId}, {$set: {"authorIds.$": targetUserId}}, {multi: true})


I had to look this up, let's throw in a doc reference:

Suggested change

await Votes.rawUpdateMany({authorIds: sourceUserId}, {$set: {"authorIds.$": targetUserId}}, {multi: true})

// https://www.mongodb.com/docs/manual/reference/operator/update/positional/

await Votes.rawUpdateMany({authorIds: sourceUserId}, {$set: {"authorIds.$": targetUserId}}, {multi: true})

jpaddison3 · 2022-07-12T22:00:18Z

packages/lesswrong/server/voteServer.ts

@@ -267,7 +271,7 @@ const checkRateLimit = async ({ document, collection, voteType, user }: {
  const oneDayAgo = moment().subtract(1, 'days').toDate();
  const votesInLastDay = await Votes.find({
    userId: user._id,
-    authorId: {$ne: user._id}, // Self-votes don't count
+    authorIds: {$ne: user._id}, // Self-votes don't count


I don't think this will work, based on my reading of mongo docs.

I tested it out and it seems to work. For instance, in the EA dev db db.votes.find({ _id: "5be4dc3ce61b803757b01324", authorIds: { $eq: "Yx4AN5v8gJBCtrN67" } }) will return 1 result and db.votes.find({ _id: "5be4dc3ce61b803757b01324", authorIds: { $ne: "Yx4AN5v8gJBCtrN67" } }) will return 0.

I guess the alternative would be db.votes.find({ _id: "5be4dc3ce61b803757b01324", $expr: { $in: ["Yx4AN5v8gJBCtrN67", "$authorIds"] } }) and db.votes.find({ _id: "5be4dc3ce61b803757b01324", $expr: { $not: { $in: ["Yx4AN5v8gJBCtrN67", "$authorIds"] } } }), but everything I've read (without having actually measured it) suggests this will be much worse for performance.

I've added another couple of tests to cover rate limiting since it's pretty impractical to test manually (it doesn't cover everything, but it does cover this query - we can expand the test in the future if necessary).

jpaddison3 · 2022-07-12T22:11:30Z

packages/lesswrong/testing/voting.tests.ts

@@ -222,6 +244,48 @@ describe('Voting', function() {
      await waitUntilCallbacksFinished();
      clock.uninstall();
    });
+    it('includes co-authored posts in the selected date range', async () => {


Yaaaaaay amazing

darkruby501

A few edge cases I don't think are necessarily covered by this. They don't necessarily matter, but that should be a deliberate choice:

Are coauthors prevented from upvoting documents they're authors on?
Coauthors miss out on karma if they're added after a post was published and first got votes
As above, coauthors risk getting negative karma if they were added after an upvote but before it was removed

Otherwise I'm a little uncertain about the direction of removing canonical "userId/author" on things. I have vague hesitations about this either requiring us to change a lot of code to handle multiple document owners (with ensuing complexity) or ending up in a mixed state where some things assume documents have a single primary owner and others expecting an array. My instinct is towards preserving the "documents, etc have canonical owners" and adding coauthors as an extension that doesn't need to be handled everywhere.

darkruby501 · 2022-07-12T23:27:51Z

packages/lesswrong/lib/collections/votes/schema.ts

-    type: String,
+
+  // The IDs of the authors of the document that was voted on
+  authorIds: {


I feel a bit uncomfortable at removing this. It will definitely break some analytics stuff for us, which is probably okay, but I have a feeling it will cause us headaches and that our general paradigm assumes documents have one canonical owner. One example, I assume revisions are still tied to one userId and am not yet sure how this PR will interact with that. (But only partway through reading it)

(I do separately think there's an anti-pattern around having both thing and thing-plural and that the existence of both email and emails has hurt us. (My ideal there is to get rid of the latter).

darkruby501 · 2022-07-12T23:29:52Z

packages/lesswrong/server/callbacks/votingCallbacks.ts

+ */
+const getDocumentOwners = ({newDocument, vote}: VoteDocTuple): string[] => {
+  const coauthors = vote.collectionName === "Posts"
+    ? getConfirmedCoauthorIds(newDocument as DbPost)


Nit: what permissions do coauthors have on documents? If they're not owners in the full sense of permissions (delete, share, draft, etc), this language could be confusing to call them owners here

darkruby501 · 2022-07-12T23:31:46Z

packages/lesswrong/server/callbacks/votingCallbacks.ts

  }
 });

 voteCallbacks.cancelAsync.add(function cancelVoteKarma({newDocument, vote}: VoteDocTuple, collection: CollectionBase<DbVoteableType>, user: DbUser) {
  // only update karma is the operation isn't done by the item's author
  if (newDocument.userId !== vote.userId && collectionsThatAffectKarma.includes(vote.collectionName)) {
-    void Users.rawUpdateOne({_id: newDocument.userId}, {$inc: {"karma": -vote.power}});
+    const owners = getDocumentOwners({newDocument, vote});


With this implementation, I think, if a post is upvoted, then a co-author is added, and then someone removes their upvote, the co-author will end up with net-negative karma.

Co-authors being added after initial publication is not uncommon in my experience since often people publish before getting our help on adding coauthors.

darkruby501 · 2022-07-12T23:33:10Z

packages/lesswrong/server/migrations/2020-09-19-updateCollectionScores.ts

-        _id: '$authorId',
-        karmaTotal: {$sum: "$adjustedPower"},
+        _id: '$authorIds',
+        karmaTotal: {$sum: "$power"},


Def want to see the migrations tested thoroughly

…their karma

oetherington · 2022-07-13T15:10:30Z

@darkruby501 Thanks for the review!

Are coauthors prevented from upvoting documents they're authors on? No, they can vote just like the main author, but they won't receive karma for their own votes (just like the main author).
Coauthors miss out on karma if they're added after a post was published and first got votes. Yes - JP and I thought this made the most sense, otherwise co-authors will suddenly receive an inexplicable chunk of karma once this goes live. It also simplifies the handling of the next point...
As above, coauthors risk getting negative karma if they were added after an upvote but before it was removed. Yes - I didn't think of this case. I've pushed a commit which prevents this, along with a unit test for it.

oetherington · 2022-07-13T15:16:49Z

@jpaddison3 I know you've already approved, but I'm assigning back to you as a sinity check because I added 7 commits since you reviewed.

oetherington · 2022-07-15T11:41:11Z

@jpaddison3 @darkruby501 This has now been merged to master and deployed successfully. Here's the timings of the migrations:

allowMultipleVoteAuthors migration (~840000 votes in 14.5 minutes)
deploy to production (~5 minutes)
allowMultipleVoteAuthors migration (10 votes in <1 second)
removeVoteAuthorId migration (~840000 votes in 14 minutes)
updateCollectionScores migration (14820 posts, 85655 comments, 26687 tagrels and 4747 users in 1 minute)

For LessWrong, it's very important that you run allowMultipleVoteAuthors before and after your next deploy. The other two migrations can be left until later if you don't have time, but allowMultipleVoteAuthors is absolutely required.

oetherington and others added 8 commits July 8, 2022 13:04

Give karma to coauthors when voting on a post

3c50400

Remove unused userGetAggregateKarma function (see recomputeKarma and …

4fdd535

…legacyKarmaMigration)

Replace votes.authorId with votes.authorIds

fcd081b

Co-authored-by: jpaddison3 <jp@centreforeffectivealtruism.org>

Update updateCollectionScores migration to allow for co-author karma

0985d3f

Update karma changes for co-authors

570d784

Update mergeAccounts script for co-author karma

afb1dc1

Update tagResolvers for co-author karma

c3b3b11

Add unit test for co-author karma

d4cf004

oetherington force-pushed the give-karma-to-coauthors branch from 1aad506 to 070e91c Compare July 12, 2022 10:07

Tidy up and refactoring

774efe0

oetherington force-pushed the give-karma-to-coauthors branch from 070e91c to 774efe0 Compare July 12, 2022 10:17

oetherington marked this pull request as ready for review July 12, 2022 10:26

oetherington requested a review from a team as a code owner July 12, 2022 10:26

oetherington requested review from Xodarap and jpaddison3 and removed request for a team and Xodarap July 12, 2022 10:26

jpaddison3 assigned Xodarap Jul 12, 2022

oetherington assigned jpaddison3 and unassigned Xodarap Jul 12, 2022

jpaddison3 approved these changes Jul 12, 2022

View reviewed changes

darkruby501 reviewed Jul 12, 2022

View reviewed changes

oetherington added 6 commits July 13, 2022 11:00

Rename owners -> authors

89b504e

Add unit tests for post vote rate limiting

c719164

Minor code review changes

d81fb87

Add unit test for updateDenormalizedContributorsList

0264cc1

Update Votes index for multiple authors

0104d17

Add resolver-only authorId to Votes

a8b9623

sync-by-unito bot assigned oetherington and unassigned jpaddison3 Jul 13, 2022

Cancelling an old vote after a new co-author is added doesn't affect …

4e88d7c

…their karma

sync-by-unito bot assigned jpaddison3 and unassigned oetherington Jul 13, 2022

oetherington merged commit dd4d579 into master Jul 15, 2022

sync-by-unito bot assigned oetherington and unassigned jpaddison3 Jul 15, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Give karma to coauthors #5250

Give karma to coauthors #5250

oetherington commented Jul 12, 2022 •

edited by sync-by-unito bot

jpaddison3 left a comment

jpaddison3 Jul 12, 2022

jpaddison3 Jul 12, 2022

jpaddison3 Jul 12, 2022

darkruby501 Jul 12, 2022

oetherington Jul 13, 2022

jpaddison3 Jul 12, 2022

oetherington Jul 13, 2022

jpaddison3 Jul 12, 2022

jpaddison3 Jul 12, 2022

jpaddison3 Jul 12, 2022

jpaddison3 Jul 12, 2022

oetherington Jul 13, 2022

jpaddison3 Jul 12, 2022

jpaddison3 Jul 12, 2022

oetherington Jul 13, 2022

jpaddison3 Jul 12, 2022

darkruby501 left a comment •

edited

darkruby501 Jul 12, 2022

darkruby501 Jul 12, 2022

darkruby501 Jul 12, 2022

oetherington Jul 13, 2022

darkruby501 Jul 12, 2022 •

edited

oetherington commented Jul 13, 2022

oetherington commented Jul 13, 2022

oetherington commented Jul 15, 2022

	await Votes.rawUpdateMany({authorIds: sourceUserId}, {$set: {"authorIds.$": targetUserId}}, {multi: true})
	// https://www.mongodb.com/docs/manual/reference/operator/update/positional/
	await Votes.rawUpdateMany({authorIds: sourceUserId}, {$set: {"authorIds.$": targetUserId}}, {multi: true})

Give karma to coauthors #5250

Give karma to coauthors #5250

Conversation

oetherington commented Jul 12, 2022 • edited by sync-by-unito bot

jpaddison3 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darkruby501 left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darkruby501 Jul 12, 2022 • edited

Choose a reason for hiding this comment

oetherington commented Jul 13, 2022

oetherington commented Jul 13, 2022

oetherington commented Jul 15, 2022

oetherington commented Jul 12, 2022 •

edited by sync-by-unito bot

darkruby501 left a comment •

edited

darkruby501 Jul 12, 2022 •

edited