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.
Comments on Should we be able to tag answers?
Parent
Should we be able to tag answers?
On some of our communities, it would be helpful to be able to label answers systematically:
-
On Code Golf, by language.
-
On Software Development, Power Users, or Linux Systems, by specific version/platform/library -- for example, if the answer to a C++ question is different for C++11 than C++14, or a browser answer is different for Firefox and Chrome, or a front-end question is different for pure Javascript or jQuery.
In some cases perhaps the question should be more specific, but it seems like in some cases it'd be better to have the answers all together. And, of course, on Code Golf, varied answer languages are expected.
It's sometimes useful to be able to just tell at a glance what an answer applies to. There are probably people still using (or maintaining code in) Java 7, so you don't want to nuke those answers, but you want the person who's looking for a current solution to a Java problem to be able to tell at a glance that this answer is for an older version.
Would it make sense to be able to add tags to answers, in addition to the tags on the question?
In addition to making answer scoping more visible, answer tags could support sorting. I'm imagining another sort option at the top of the answers alongside "Score" and Activity", and maybe also showing answer tags in the table of contents. I'm also imagining that this would be something communities would opt into, since it doesn't make sense on every community.
I think tag hierarchies are orthogonal; while (if they exist, which I haven't checked) C++11 and C++14 should be children of C++, a challenge on Code Golf doesn't have any question-level language tags at all.
This isn't a bad idea. I'd like the tag system to have some more features. Why tags on answers could be useful Sys …
1y ago
This seems like a good idea from a programming or computer hardware and software perspective. Choosing the version of …
3y ago
Examining precedent The Stack Exchange network has the core of this feature: you can write `[tag:tag-name]` in the bo …
1y ago
This should probably be per-community configurable. Since even on Code Golf, not all tags are meaningful on answers, one …
3y ago
It sounds like a feature of very limited use. I agree that it would be neat for Code Golf, where different answers are p …
3y ago
Post
Examining precedent
The Stack Exchange network has the core of this feature: you can write [tag:tag-name] in the body of a question or answer to get a button (really an a tag, just like here) that works just like the tags underneath a post.
-
Tags that are specially marked on the site, still get marked that way. Tags that haven't been created, show up all the same anyway, and just link to a "tag" with zero questions.
-
Questions and answers do not show up in a tag search because of tag markup used within them, only based on actual tags applied to the question.
-
It doesn't support sorting. I don't think sorting makes sense here anyway; the value-add would be filtering, to hide answers that do (or don't) include a particular tag.
-
It doesn't show up in a table of contents, because there is no table of contents.
-
It gets used very actively on some network sites (such as the Law one) and practically never anywhere else.
-
Where it does get used, it's a huge value-add: it allows the Law site to have people ask general questions about legal practice, and get answers that are specific to a legal jurisdiction - which allows everyone to compare and contrast how the law works in different parts of the world.
-
There is no restriction at the technical level on which tags can be specified where. It's purely the social convention of each individual site.
-
Full endorsement
I strongly recommend embracing and extending this feature, based on what I've seen. The upsides are clear and the downsides have proven themselves irrelevant in practice.
-
We don't need or want to make such a feature configurable by community.
-
In communities that don't already use the feature (or have meta discussions about it), it won't be discoverable. People who don't see it won't think of using it.
-
Abuse also isn't a problem: while the necessary Markdown could appear anywhere in a post (and any additional features that care about them, probably should search the post for them), in practice we see that everyone on Law uses it only at the top of an answer, and not at all in questions.
-
Similarly, in practice people don't post off-topic answers on questions that already specified a jurisdiction in the tags, because it's already well understood what the purpose is. Again - communities come to consensus through the normal means, and prominent members lead by example. (This is the main reason we don't see the feature used on Stack Overflow, even though I think there are definitely cases where it would be useful for Software.)
-
-
On the other hand, related to that, there could be cases where it's useful to broaden a question, anyway. For example, on Software, suppose a confused beginner asked about a logic error related to De Morgan's laws, and tagged it with the language that was actually used. The community might decide it's better to remove or replace the language tag, collaborate on a "main" language-agnostic answer, and then add language-tagged answers with more specific examples of the syntax.
Contrary to a previous suggestion, I don't think it would be particularly useful to tag version-specific answers on Software for Python. Of course, that would be up to a later Software Meta discussion, but my main argument is that we don't have minor-version tags (and they have proven mostly useless and counterproductive on Stack Overflow), and 2.x is a long-enough-dead parrot that special justification should be required to post any new content related to it (i.e., explicitly examining a historical perspective). If anything, we should tag according to Python features added in new minor versions, like [python-fstring] or [python-match-case].
On the other hand, there are a ton of common tasks where Numpy might be able to help or offer something that's more efficient or elegant, but it's also perfectly possible to do, say, with ordinary Python lists. For future readers, it would often work better to collect the "vanilla" and Numpy-specific answers in the same place, even if OP specifically wanted one or the other. This is a great reason for supporting filtering and for a TOC to summarize tags that were applied to answers. The filter could even be persistent and user-specific, so that e.g. someone who doesn't have any interest in Numpy could filter answers using it by default, and browse Python Q&A at leisure.
0 comment threads