Skip to main content
replaced http://meta.stackexchange.com/ with https://meta.stackexchange.com/
Source Link

Ah, time to resurrect my good old Implicit tagging hierarchyImplicit tagging hierarchy suggestion: While a question about is obviously about that specific version of , using the latter tag additionally is nonsense to me - it wastes space for a tag that is already implicitly present, but everyone has to use a visual-studio* wildcard (which fails to render correctly when typing [tag:visual-studio*] by the way...) and this is not possible for other tags where the implied hierarchy is not visible in the name, e.g. in . That's why I suggested an implicit tagging hierarchy, where adding a tag for which unambiguous parent tags exist (a question in should require the tag explicitly since it could also be e.g. or , while both and are implicit parents) those tags should be treated as present on search/ignore/favorite queries but not be explicitly waste one of the five tag slots.

Ah, time to resurrect my good old Implicit tagging hierarchy suggestion: While a question about is obviously about that specific version of , using the latter tag additionally is nonsense to me - it wastes space for a tag that is already implicitly present, but everyone has to use a visual-studio* wildcard (which fails to render correctly when typing [tag:visual-studio*] by the way...) and this is not possible for other tags where the implied hierarchy is not visible in the name, e.g. in . That's why I suggested an implicit tagging hierarchy, where adding a tag for which unambiguous parent tags exist (a question in should require the tag explicitly since it could also be e.g. or , while both and are implicit parents) those tags should be treated as present on search/ignore/favorite queries but not be explicitly waste one of the five tag slots.

Ah, time to resurrect my good old Implicit tagging hierarchy suggestion: While a question about is obviously about that specific version of , using the latter tag additionally is nonsense to me - it wastes space for a tag that is already implicitly present, but everyone has to use a visual-studio* wildcard (which fails to render correctly when typing [tag:visual-studio*] by the way...) and this is not possible for other tags where the implied hierarchy is not visible in the name, e.g. in . That's why I suggested an implicit tagging hierarchy, where adding a tag for which unambiguous parent tags exist (a question in should require the tag explicitly since it could also be e.g. or , while both and are implicit parents) those tags should be treated as present on search/ignore/favorite queries but not be explicitly waste one of the five tag slots.

Migration of MSO links to MSE links
Source Link

Ah, time to resurrect my good old Implicit tagging hierarchyImplicit tagging hierarchy suggestion: While a question about is obviously about that specific version of , using the latter tag additionally is nonsense to me - it wastes space for a tag that is already implicitly present, but everyone has to use a visual-studio* wildcard (which fails to render correctly when typing [tag:visual-studio*] by the way...) and this is not possible for other tags where the implied hierarchy is not visible in the name, e.g. in . That's why I suggested an implicit tagging hierarchy, where adding a tag for which unambiguous parent tags exist (a question in should require the tag explicitly since it could also be e.g. or , while both and are implicit parents) those tags should be treated as present on search/ignore/favorite queries but not be explicitly waste one of the five tag slots.

Ah, time to resurrect my good old Implicit tagging hierarchy suggestion: While a question about is obviously about that specific version of , using the latter tag additionally is nonsense to me - it wastes space for a tag that is already implicitly present, but everyone has to use a visual-studio* wildcard (which fails to render correctly when typing [tag:visual-studio*] by the way...) and this is not possible for other tags where the implied hierarchy is not visible in the name, e.g. in . That's why I suggested an implicit tagging hierarchy, where adding a tag for which unambiguous parent tags exist (a question in should require the tag explicitly since it could also be e.g. or , while both and are implicit parents) those tags should be treated as present on search/ignore/favorite queries but not be explicitly waste one of the five tag slots.

Ah, time to resurrect my good old Implicit tagging hierarchy suggestion: While a question about is obviously about that specific version of , using the latter tag additionally is nonsense to me - it wastes space for a tag that is already implicitly present, but everyone has to use a visual-studio* wildcard (which fails to render correctly when typing [tag:visual-studio*] by the way...) and this is not possible for other tags where the implied hierarchy is not visible in the name, e.g. in . That's why I suggested an implicit tagging hierarchy, where adding a tag for which unambiguous parent tags exist (a question in should require the tag explicitly since it could also be e.g. or , while both and are implicit parents) those tags should be treated as present on search/ignore/favorite queries but not be explicitly waste one of the five tag slots.

Source Link
Tobias Kienzler
  • 17.8k
  • 2
  • 42
  • 97

Ah, time to resurrect my good old Implicit tagging hierarchy suggestion: While a question about is obviously about that specific version of , using the latter tag additionally is nonsense to me - it wastes space for a tag that is already implicitly present, but everyone has to use a visual-studio* wildcard (which fails to render correctly when typing [tag:visual-studio*] by the way...) and this is not possible for other tags where the implied hierarchy is not visible in the name, e.g. in . That's why I suggested an implicit tagging hierarchy, where adding a tag for which unambiguous parent tags exist (a question in should require the tag explicitly since it could also be e.g. or , while both and are implicit parents) those tags should be treated as present on search/ignore/favorite queries but not be explicitly waste one of the five tag slots.