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 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.