-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change algorithm of follow recommendations #28314
Conversation
17eccfb
to
cdba643
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #28314 +/- ##
==========================================
+ Coverage 83.67% 83.70% +0.02%
==========================================
Files 1038 1039 +1
Lines 28255 28221 -34
Branches 4555 4549 -6
==========================================
- Hits 23642 23622 -20
+ Misses 3485 3470 -15
- Partials 1128 1129 +1 ☔ View full report in Codecov by Sentry. |
b692dfb
to
e11b233
Compare
b722fa3
to
5bb804d
Compare
e63510c
to
3fc259d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems sensible overall, but I have a hard time evaluating the actual algorithms. On my single-user instance:
AccountSuggestions::FriendsOfFriendsSource
does not return a single suggestionAccountSuggestions::SimilarProfilesSource
does return suggestions, but no one I would followif I weren't following them already (as pointed out in inline comments, themust_not_clauses
filtering them out are not actually used in the final query)
From my own perspective (single-user server with around 250 follows), those recommendations perform worse than the existing ones in that it doesn't recommend people I would actually consider following. That being said, I do not use this feature either way.
Also, this PR requires re-indexing accounts, this needs to be mentioned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the inline comment, there's an API design issue I'm wondering about: the API returns, along with suggestions, which source they're from. However, there is no way to select or filter them, which makes the source classification much less useful imho.
The |
This pull request has merge conflicts that must be resolved before it can be merged. |
Co-authored-by: Claire <[email protected]>
ba14b61
to
5ddcf67
Compare
5ddcf67
to
c012e5f
Compare
This pull request has resolved merge conflicts and is ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine overall, although I'm still not sure about the quality of the recommendations, especially on small servers.
Also, this requires re-indexing accounts for the “similar profiles” source to work, we'll need to remember to add that to the release notes.
Is this re-indexing in ES or something else? |
ES. You need to run |
I do believe for minorities that have opted into discovery, there should be a bump that allows those accounts better options to be found. |
@outlaw-dame I don't have an issue with this, but I suspect the implementation would be messy. Presumably you'd either need to skim profile data for specific keywords you wanted to bump, or you'd need to add profile options for users to self-claim that they should be included (which would need to be federated, since you don't want to only recommend local users). I'm guessing it would probably be preferable to base it on profile data so there isn't a check box people can just check for growth hacking, but then someone would need to maintain a list of key words or phrases that should trigger such a bump. |
Blocked persons(individual block + server block) are listed on follow suggestion by "friends_of_friends" |
Co-authored-by: Claire <[email protected]>
Replace "past interactions" algorithm with "friends of friends" while respecting the "show follows and followers" and "feature profile in discovery algorithms" privacy settings. Cleans up a lot of the code surrounding follow recommendations. We can avoid maintaining sorted sets per language for global follow recommendations in Redis when the materialized view query is fast enough.
Fixes MAS-171