I think you’re underestimating the difficulty in getting up to 100 karma.
I don’t think straight number limits like this are going to work well. Let’s take two new users Alice and Bob, and stipulate that, using gaming terminology, Alice is a casual and Bob is an elitist jerk. Alice might well take a month or two or three to accumulate 100 karma in the course of her ordinary use of LW. Bob, being who he is, will minmax the process and get his 100 karma in a couple of days.
Managing the power gap between casuals and elite minmaxers is a big problem in multiplayer games and it doesn’t look like an easily solved one.
If we are talking about the criteria for the promotion to the full vote-wielding membership of LW, you are not limited to looking just at karma.
For example: Promote to full membership when (net karma > X) AND (number of positive-karma comments > Y) AND (days when posted a positive-karma comment > Z).
Implementation shouldn’t be difficult, given how all these conditions are straightforward SQL queries.
A more general question is the trade-off between false positives and false negatives. Do you want to give the vote to the newbies faster at the cost of some troll vandalism, or do you want to curtail the potential for disruption at the cost of newbies feeling themselves second-class citizens longer?
If what should be straightforward SQL queries are too difficult to implement, LW code base is FUBARed anyway.
Anyone wants to write another middle layer which will implement normal SQL on top of that key-value store implemented on top of normal SQL? X-D
A bit more seriously, LW code clearly uses some ORM which, hopefully, makes some sense in some (likely, non-SQL) way. Also reading is not writing and for certain tasks it might make sense to read the underlying Postgres directly without worrying about the cache.
I don’t think straight number limits like this are going to work well. Let’s take two new users Alice and Bob, and stipulate that, using gaming terminology, Alice is a casual and Bob is an elitist jerk. Alice might well take a month or two or three to accumulate 100 karma in the course of her ordinary use of LW. Bob, being who he is, will minmax the process and get his 100 karma in a couple of days.
Managing the power gap between casuals and elite minmaxers is a big problem in multiplayer games and it doesn’t look like an easily solved one.
I think straight number limits give us the most usefulness for the difficulty to implement. If you have other suggestions, I’m interested.
If we are talking about the criteria for the promotion to the full vote-wielding membership of LW, you are not limited to looking just at karma.
For example: Promote to full membership when (net karma > X) AND (number of positive-karma comments > Y) AND (days when posted a positive-karma comment > Z).
Implementation shouldn’t be difficult, given how all these conditions are straightforward SQL queries.
A more general question is the trade-off between false positives and false negatives. Do you want to give the vote to the newbies faster at the cost of some troll vandalism, or do you want to curtail the potential for disruption at the cost of newbies feeling themselves second-class citizens longer?
Very funny.
If what should be straightforward SQL queries are too difficult to implement, LW code base is FUBARed anyway.
Anyone wants to write another middle layer which will implement normal SQL on top of that key-value store implemented on top of normal SQL? X-D
A bit more seriously, LW code clearly uses some ORM which, hopefully, makes some sense in some (likely, non-SQL) way. Also reading is not writing and for certain tasks it might make sense to read the underlying Postgres directly without worrying about the cache.