Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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

60%
+1 −0
Q&A Suggestion for allowing to mark answers as "accepted", "outdated" or "dangerous"

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

posted 11mo ago by matthewsnyder‭

Answer
#1: Initial revision by user avatar matthewsnyder‭ · 2023-06-09T21:20:35Z (11 months ago)
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.