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.
Indicate stale reactions based on user activity
Reactions are currently used on CD to:
- Confirm an answer worked (similar to accepting an answer on SO)
- Show that an answer is dangerous
- Indicate interest in participating in a proposed CD site
Some of these have enduring meaning. For example, if rm -rf * was dangerous 50 years ago, it is still dangerous now. Others go stale. For example, if I indicate that I would be a casual user of a proposal, and then forget CD exists for the next 3 years, that reaction is not as meaningful as a fresh one. Another example: A Python 2 answer may have been accepted in 2010, with the asking account now inactive, and basically it will never get corrected even though Python 2 is now obsolete - this became a significant occasional problem on SO after some years.
My solution:
- Define a time horizon
t_maxfor each reaction. This indicates the CD devs' best guess for how long that reaction is relevant for.t_maxcan be infinity. - When displaying reactions, check
t_age: how long it's been since the user's last login. - If the
t_age > t_max, display the reaction as "stale" or "old" and grey it out in the UI (halve the saturation?). Each stale reaction should also have mouse over text like "Reactions made by accounts which have not been active in over 30 days".
This is a live calculation, in that stale reactions can become fresh again when the user logs in after a long hiatus.
This system can be gamed by writing a script that logs in every day, to artificially keep your own reactions fresh indefinitely. I don't think anybody will bother for a long time.
I would prefer to give readers information rather than infer conclusions (sometimes right, sometimes not). We have an ex …
1y ago
Argument against Quite simply, none of the available reactions has a clear and pressing need for such a marking …
1y ago
Wary of trying to be too general Although I like the idea of this for making sure indications of interest don't last in …
1y ago
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
I would prefer to give readers information rather than infer conclusions (sometimes right, sometimes not). We have an existing request to show reactions in history somehow -- specifically, readers need to know if that outdated/dangerous reaction was before or after a substantial edit.
Maybe we can add the timestamp of the newest reaction (of a type) to the tooltip when viewing the reaction?
Argument against
Quite simply, none of the available reactions has a clear and pressing need for such a marking.
"Works for me" can be directly contradicted
The only good reason to mark a "works for me" reaction as "stale" is because the solution is now obsolete - and there is already a reaction explicitly for indicating that. We don't have to predict a timeline for a hypothetical Python 4; if and when it happens, we can mark answers that are 3.x-specific after determining that they are 3.x-specific (while leaving alone answers that aren't affected by the version bump, but are just as old).
"outdated" and "dangerous" tags don't go bad
As already noted.
If a technique is outdated, it can't stop being outdated.
If a technique is dangerous, it is extremely unlikely to become safe automatically; even if new library support appears, the answer will probably have to be edited to take advantage. It would be incredibly poor practice on the part of e.g. a library maintainer to secure a fundamentally insecure technique, years later, and reuse all the same names for it.
Even if it did happen that version X of a library makes previously-unsafe technique Y safe, with no required alteration to the code, the answer is still in a sense outdated - because it doesn't account for the library version required for security (a version number that was unknowable at the time of writing).
If an answer is edited, years later, such that it goes from being outdated or dangerous to not being thus, then that in turn can be disputed by adding appropriate "Works for me" tags.
"interest" becoming stale isn't relevant
Either the site went live, in which case there's no reason to care about book-keeping on the process that got that far; or the proposal has been in discussion for so long that it's probably time to face reality and reject it (probably without prejudice); or else it's one specific user who has reconsidered the proposal and should be responsible for actively retracting the reaction.
Argument in favour
Because answers do get edited in ways that could immediately and directly invalidate a reaction, and because people do leave communities over time (and therefore could leave a reaction and then fail to see an edit that invalidates the reaction), and because sometimes people will just stubbornly disagree that their reaction is invalidated: I agree that we should at least be able to see the dates for reactions. Expecting a mouseover might be too much; I like OP's idea of reduced saturation for older reactions - but instead applied to reactions where all of the following apply:
- the question has been edited;
- the reaction was made before the most recent edit;
- the most recent edit is older than some time threshold (either configurable by community, or dependent on the community's level of activity);
- the reacting user has been relatively inactive since that edit.
Mouseover guidance would suggest something like: "it's possible that the reacting user hasn't fully considered edits made after making the reaction".
Wary of trying to be too general
Although I like the idea of this for making sure indications of interest don't last indefinitely on Codidact Proposals, trying to find a general use for expiring reactions on existing Codidact communities might end up stretching one tool across too many use cases. Perhaps we would be better with several different solutions for different problems.
Alternative solutions for proposals
This has made me think about how else we could measure interest in a proposal without needing to modify the reactions system.
Measuring activity rather than intentions
Even with expiring reactions, a user who claims they will be a user of the proposed community may turn out to not be interested enough to interact often. Keeping a reaction on a proposal up to date by regularly visiting is much less effort than making meaningful interactions like voting, posting, and editing. Perhaps we should focus more on measuring directly how much activity a proposal is seeing.
Now that proposals are in a community of their own, with questions and answers and their own Meta category, we get a much better impression of the activity a finished community would see, because much of that activity can already happen in the proposal. Could we add statistics to proposals that show how much of each activity type is happening? This would show what people are already doing for that proposal, rather than what they claim they will do in the future.
Charts in the Descriptions post
This could be hosted in the Descriptions post for a proposal, as a collection of charts showing different types of activity. Possible charts could be:
- Number of views (of questions attached to the proposal, the proposal's tag, and the proposal's Descriptions post).
- Number of questions.
- Number of answers.
- Number of unanswered questions.
- Number of votes cast.
Each of these could be shown against time, so we can easily see if a proposal has steady activity or just a spike in the first month and then less (or a steady increase over time).
1 comment thread