Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Post History
I like the idea because these have been known issues in other places for some time. However, is it really needed? The classic justification for this is an old, obsolete answer that has hundreds o...
Answer
#1: Initial revision
I like the idea because these have been known issues in other places for some time. However, is it really needed? The classic justification for this is an old, obsolete answer that has hundreds of upvotes because it was correct *at the time*. Now better answers have been given, but first they have to catch up to the hundreds-strong old one. Many of the people who originally upvoted the old answer will not bother to go back and review their votes. Some may have abandoned their account. You need a way to bypass this. But if you thinking about it then, this logic is just arriving at some way of negating bona fide votes. Then you should really discuss it generally, and ask how and when should vote negation be allowed. I think it becomes evident that this approach has fundamental problems that will taint every special cases (like the outdated status). Comments are supposed to be the elegant solution to this inertia problem. Another one is to support biasing votes by recency. But of course it's hard to calibrate recency vs. majority. The real problem here is the tyranny of the ancestry. Whoever voted early, gets to impose their will on the future community, indefinitely, and there is no recourse. Here's my idea: * Do not add any new statuses or categories of votes (like accepted, outdated). * Retain comments - comments are not votes. * Institute an "expiration date" on all votes. This can be arbitrary, for example, 1 year. However, it might be better to have an equation for correlating it to the activity, size and nature of the section (maybe webdev votes should go stale faster than history votes). * Expired votes are considered "stale". They are not removed and still act exactly as normal votes, however the score display does indicate what % is fresh. * Add filters that discount stale votes. Using these is optional. * Show notifications to users when their vote goes stale, so they can review and refresh the vote if they want.