19

I'm getting sick of version numbers in tag names (aka version tags).

Look,

I just want them all to be just . They are all about JSF. I browse and answer questions about JSF. I don't want to browse in all those different tags. I don't want gold badges for both and . I can't hammer a duplicate question because I don't have a gold badge for that.

Across years I observed that a version tag is usually only picked by the asker when a "relatively new" or "relatively old" version is being treated in the question. When the "currently mainstream" version is being treated, or when the asker is "more proficient" in the language, then askers often just pick the versionless . While moving in time, this may cause confusion by future readers when the version isn't explicitly specified anywhere in the question. I try to maintain them by adding/removing the version tag depending on its relevance, and by adding the versionless tag when it's absent. It only feels a neverending story. I'm sure other tag caretakers also have mixed feelings on this.

I propose to normalize the version from the tag name:

  • Ban version numbers in tag names in the model (not in the UI).
  • Add an optional single-choice version field to the Tag entity in the model.
  • Users with edit privileges (no suggested edits please) must be able to change versions. Users with gold tagbadges must be able to add and edit versions. I'd imagine the version edit thing to be reachable via that tag info popover (when you hover the tag). Tags themselves however should look exactly the same, the version just separated with e.g. a hyphen from the tag name.

When in place, migration of existing version tags should be piece of cake. There's apparently already a script in place which recognizes version tags, it could be reused to re-match current tags and extract the version from it into the new version field.

The alternative would be to automatically add the versionless tag when a version tag is being used. But this is IMO only tag pollution.

Thoughts?


I'm posting this on meta.se instead of meta.so because version numbers aren't only on SO a problem, but on basically all HW/SW related sites.

  • "Add an optional single-choice version field to the Tag entity." - But what if a question applies to multiple versions? eg. "I'd like it to try make it work on 3.2 or 4.0, but I can't upgrade to 5.0". – SuperBiasedMan Oct 16 '15 at 15:56
  • 4
    Or "how can I do this [python-2.x] construct in [python-3.x]". – Antti Haapala Oct 16 '15 at 17:05
  • @SuperBiasedMan: 4.0 would be fit. – BalusC Oct 16 '15 at 17:09
  • @Antii: 3.x would be fit. – BalusC Jul 27 '16 at 20:08
  • "I'm posting this on meta.se instead of meta.so" why not post at meta.so specifically for the JSF tags? There are many improperly tagged questions on a daily basis. – Jasper de Vries Mar 8 '18 at 10:20
  • @JasperdeVries: because I'm not requesting for retagging/synonymizing. I do find version information useful, but it's absolutely not practical in its current form. If we retag now, and this proposal gets implemented later, we lose all original version information. – BalusC Mar 8 '18 at 12:08
  • Point taken. Indeed, it's not practical right now. – Jasper de Vries Mar 8 '18 at 12:16
17
+500

There is an unnecessary amount of confusion caused by version tags. I agree with the motivations behind this proposal.

  • Askers often choose a version tag when the question really isn't version specific, often because they don't understand the problem well enough (hence the question).
  • If a user has a gold badge in a language tag, they're suddenly not considered an expert by the system if the language tag also happens to have a version.
  • Answerers miss out on questions that are not tagged with the base language because they are unaware that they need to follow those as well.
  • Although it's possible to add a tag like [python-*] to the favorite tags, this also picks up library tags in addition to version tags, and users probably don't want to favorite all libraries for a language.

Banning version from tags altogether is too extreme a solution. The tags are a succinct, standard way to convey that information. Your suggestion to move the versions to a special tag field, while a cool concept, seems like a lot more overhead than what we have now.

Simply allowing version tags to imply the base tag would be enough. This way we don't have multiple tags where one tag would do, but still get all the information across.

  • Points earned on a version tag would just go to the base tag.
  • Privileges earned on the base tag would apply to the version tags.
  • Viewing/searching the base tag would also show posts with only a version tag. Viewing a version tag would show posts with that specific tag. Ignoring/excluding a version tag would ignore it on the base tag.
  • Adding multiple version tags would still work for cases where multiple versions are relevant.

Assuming versions in tags are already detected as you mention, this would be just as much work to implement, without the additional overhead of a new interface for tags.

  • so you're basically talking about a tag hierarchy? How would you correlate version tags to "parent tags"? What about products that change their names between versions? (JBoss, Eclipse, …) – Vogel612's Shadow Oct 16 '15 at 15:47
  • @Vogel612'sShadow for cases where names change, you're right, this wouldn't handle that. But this would still improve the situation for all the cases where the name doesn't change. The op indicated that versions were already being detected in tags, it doesn't seem that much of a stretch to strip the version from the tag for matching purposes. – davidism Oct 16 '15 at 15:51
  • @Vogel612'sShadow I don't know the full history of tag hierarchy suggestions, but I feel like that phrase implies a much more complex system than basically aliasing tags with versions to the base tag. – davidism Oct 16 '15 at 15:53
  • "Privileges earned on the base tag would apply to the version tags." - Does this always work though? What if there's significant differences between versions and someone who's very proficient in 1.0 is an utter novice at version 7.2? – SuperBiasedMan Oct 16 '15 at 15:54
  • 3
    @SuperBiasedMan Is there an actual case where an expert in one version would be considered a total beginner in another, to the point where they wouldn't be able to get up to speed and identify duplicates? Users with gold badges are considered trusted, I don't think assuming they will suddenly make poor decisions is productive. I'm very conscious of checking that a question is actually a duplicate before I hammer it, if I found I wasn't familiar enough with a new version I'd just leave it for someone else. – davidism Oct 16 '15 at 15:58
  • @davidism That's a good point, the privilege is limited enough that it wouldn't be overly problematic in those rare cases. I don't know a lot about how the gold badge privilege is used and whether it makes a significant difference. Are you suggesting that there'd be no longer version specific gold badges too? I inferred that before but I'm not sure if you meant it. – SuperBiasedMan Oct 16 '15 at 16:01
  • 1
    @SuperBiasedMan version specific badges could still be awarded, but a badge in the base tag would be enough to grant privileges in the version tags. – davidism Oct 16 '15 at 16:02
  • 1
    After meditating a weekend on it, I think this is an awesome middle-ground. – BalusC Oct 19 '15 at 8:53
4

I don't have a problem with version tags. They allow for simple searching, communication, and categorization of important information.

In defense of the current system:

  • a question can apply to multiple, but specific versions (e.g. , ), which means you'd have to replicate this functionality in the new field that you propose
  • a tag can help suggest better alternatives (e.g. but using to-be-deprecated behaviors)
  • I think the tags look pretty cool visually. I don't want to feel like I'm answering questions for free in a spreadsheet.
  • it works reasonably well.

I believe that your complaint would be better solved by hierarchical/relational inclusion for moderation actions (e.g. rights on apply to ).

  • 1
    How exactly would the normalized form be unsearchable / uncommunicatable / uncategorizable? I'd imagine it's better as it has become normalized. A normalized version is of course also visible in the tag "button". An hierarchial/relational inclusion would still need a normalization change in the model. – BalusC Oct 16 '15 at 15:02
  • How would changing the input region lead to meaningful improvement? – 89c3b1b8-b1ae-11e6-b842-48d705 Oct 16 '15 at 15:51
4

While version tags add some (a lot of) value to the situation, I completely agree that there are better ways to do it.

I, personally, would like some sort of indication as to version. (What version of do they use? What version of do they use?) These are pretty important in some cases. (C#6.0 has the null-conditional operator which makes many tasks much simpler, .NET has MethodImplOptions.AggressiveInlining, which is only available in 4.5+.) Versions convey very important information.

Barring version number from tags seems a bit extreme, but if there were another field for them (or a field on the tag, as you suggest) it would make things considerably simple. It would also make it easier to identify. (On Code Review it is very important to know whether something is Python 2, or Python 3, for example.) As there is no standard way of indicating version, it would be helpful to have something.

On the other hand, this is what comments are for. If it's important to know the version, then a simple "What version of ____ are you using?" should help eliminate confusion. And, if it's in the comments, it's easy for others to find it. (Assuming everyone reads the comments to begin with.) (Included only for devil's advocacy.)

Personally, I would much appreciate something like a field on the tag, it would make it much easier to identify, and put it in the same location for each question. (Which is what we need: a standard way to identify versions. I'm sure that's a lot of the reason why they exist.)

  • 1
    Users who don't tell version in question are unlikely to use version tags the right way. At least, this is what I've observed over years. There are even users who throw in all possible versions for the sake of attention. Users who know to find the version tag, but couldn't find/use that specific one because it isn't available yet are likely to just mention it in the question already. – BalusC Oct 16 '15 at 17:13
  • @BalusC Which is why I completely agree with your mention of adding a field to the tag, to help identify the version down to one option per tag. (And since we can't add the same tag twice, that helps eliminate some issues.) – Der Kommissar Oct 16 '15 at 17:40
  • I think we need a “this question was asked about version X” field that's separate from tags, and there should only be version-specific tags for things like major language versions where there continue to be a lot of new questions about older versions—and maybe only when they break compatibility with older versions. And then another field that indicates “no longer applies as of version Y” that can be filled in whenever it becomes apparent that the question no longer applies to newer versions. This would allow for searches to be restricted to before/after/during a range…or not. – Chris Page May 11 '16 at 5:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .