Possible solution 1: Smaller communities; Dunbar's number. I know it's been suggested before, but here it is again... When everybody knows everybody, people are nicer. Just create one unique, isolated instance of the site for every X number of users. Distribute current users randomly (or whatever) among the instances. Assign new users to the least populous instance. If an instance gets over max_number of users, split it in two.
Don't bother trying to do fancy stuff like connecting votes between communities; if something is really good people from each community will submit it separately. Also, it might be nice to be able to move between communities... but that sounds like something for version 2.
You could have these smaller communities run in parallel with the main site if this seems like too big of a shift.
Possible solution 2: Not sure if this really addresses the issue squarely -- but what if, when ranking stories and/or comments, you factor in the number of votes in the intersection between the current user and the submitter/commenter. Something like:
define votes(username): return ids of last n upvoted items for username
Just use the original algorithm if the user hasn't yet cast n votes.
One man's garbage is another man's gold, as they say.
You could do something similar by checking downvotes as well. If two people are polar opposites (one person upvotes stuff the other downvotes), then comments by one could be greyed out or hidden for the other.
If there were simply a box I could check to make my votes public, then maybe somebody could write a Chrome or Firefox extension to pull this data and handle the re-ranking.
Neither of these two ideas would be perfect, but I think they would improve the user experience significantly. If nothing else they would be interesting experiments.
Possible solution 1 sounds like a horrible idea. By fragmenting the community it would fragment the knowledge, quite a high price to pay for clean comments.
I don't know, I find that in smaller web communities I tend to participate more, because I know my voice is more likely to be heard. And if everyone knows everyone than people would be more easily remembered for making good comments. That would give them more of an incentive to be helpful and constructive. So the knowledge loss might not be as great as it would seem.
And communities could still be visible to everyone, even if only members of that community can participate. Then if there's a really good comment in one community, someone from another could just copy and paste it over.
This would kill HN almost instantly. Knowing that there is a very real chance that I'm in a rather boring and mundane segment of the community, solely due to being user #232 instead of user #231, would make me think twice about joining and participating.
Solution 2 is very interesting and a form of instant personalization. "You will like this if this is the sort of thing you like." People who want to seek out disagreement/incongenial views might be able to turn it off should they so please.
With the right data structure you could do this with a single matrix-vector multiplication per page view.
Comments
Possible solution 1: Smaller communities; Dunbar's number. I know it's been suggested before, but here it is again... When everybody knows everybody, people are nicer. Just create one unique, isolated instance of the site for every X number of users. Distribute current users randomly (or whatever) among the instances. Assign new users to the least populous instance. If an instance gets over max_number of users, split it in two.
Don't bother trying to do fancy stuff like connecting votes between communities; if something is really good people from each community will submit it separately. Also, it might be nice to be able to move between communities... but that sounds like something for version 2.
You could have these smaller communities run in parallel with the main site if this seems like too big of a shift.
Possible solution 2: Not sure if this really addresses the issue squarely -- but what if, when ranking stories and/or comments, you factor in the number of votes in the intersection between the current user and the submitter/commenter. Something like:
define votes(username): return ids of last n upvoted items for username
item_score *= (length(intersection(votes(user_x), votes(user_y))) / (n / 2))
Just use the original algorithm if the user hasn't yet cast n votes.
One man's garbage is another man's gold, as they say.
You could do something similar by checking downvotes as well. If two people are polar opposites (one person upvotes stuff the other downvotes), then comments by one could be greyed out or hidden for the other.
If there were simply a box I could check to make my votes public, then maybe somebody could write a Chrome or Firefox extension to pull this data and handle the re-ranking.
Neither of these two ideas would be perfect, but I think they would improve the user experience significantly. If nothing else they would be interesting experiments.
Possible solution 1 sounds like a horrible idea. By fragmenting the community it would fragment the knowledge, quite a high price to pay for clean comments.
I don't know, I find that in smaller web communities I tend to participate more, because I know my voice is more likely to be heard. And if everyone knows everyone than people would be more easily remembered for making good comments. That would give them more of an incentive to be helpful and constructive. So the knowledge loss might not be as great as it would seem.
And communities could still be visible to everyone, even if only members of that community can participate. Then if there's a really good comment in one community, someone from another could just copy and paste it over.
This would kill HN almost instantly. Knowing that there is a very real chance that I'm in a rather boring and mundane segment of the community, solely due to being user #232 instead of user #231, would make me think twice about joining and participating.
Solution 2 is very interesting and a form of instant personalization. "You will like this if this is the sort of thing you like." People who want to seek out disagreement/incongenial views might be able to turn it off should they so please.
With the right data structure you could do this with a single matrix-vector multiplication per page view.
> Possible solution 1:
I actually built this, but never put it up on a server.
Cool. Might as well put it up somewhere, right? Of course, you'd face the big chicken and egg problem of getting users.
Yeah, I didn't want to have to actually work on it, just trying out an idea. The code itself has since been lost in a backup mishap.