Comments on Tag creation/deletion criteria
Parent
Tag creation/deletion criteria
Because of recent discussions regarding whether vague terms like voltage and ground should be valid tag names or not, it is clear that we have no consistent rules here. These terms are about on-topic matters, but they are vauge and ambiguous and cannot "stand alone" without other tags.
In comparison, Stack Exchange and in particular Stack Overflow are super-strict about tags and particularly so when it comes to deletion of tags. They have a huge system error on the site where creating a tag is somewhat simple and can be done by a single person, but getting rid of a tag needs to involve some 10 to 50 people including moderators in a "burnination process". The criteria they use can be found here:
- Does it describe the contents of the questions to which it is applied? and is it unambiguous?
- Is the concept described even on-topic for the site?
- Does the tag add any meaningful information to the post?
- Does it mean the same thing in all common contexts?
A tag must fail ALL of those tests in order to be considered for burnination. In any case, the ultimate criterion for burnination is whether the tag is actually causing harm.
Codidact does probably not benefit from having as strict rules as SO - in particular it does definitely not benefit from making the same mistake as SO:
Deleting/renaming a tag must be as effortlessly as creating that tag in the first place.
Consequently, if we want a high bar for deleting/renaming tags, we should raise the bar for creating tags accordingly as well. Or otherwise the whole system will eventually collapse as it did on SO.
With that in mind, I think we can use the SO criteria as a basis and form new rules for tags here. I think perhaps the last sentence in the above quote is worth particular consideration - does the tag cause active harm, such as confusion or wrong use of the tag?
Post
I agree with the answer of Lundin except for point 3 disambiguation.
Regarding 3), in case a term does have several different meanings and all meanings are on-topic, then the most common/jangon use of the term takes precedence.
Instead, I would proceed in this way:
In case a term has several different on-topic meanings, it should never be a main tag. New, more precise tags, should be created for all the different meanings [1]. Then the ambiguous term should be either (A) placed as synonym of one of those different tags, or (B) put in a blacklist as too ambiguous. The choice between A and B is a judgement call, depending on what would cause less confusion in the specific case. If case (A) is chosen, a warning should be put in the guidance text of both tags.
For example, in the case of PID, I would create two non-ambiguous tags:
-
PID-controller(with a spelled out synonymproportional-integral-derivative-controller, as per the guidelines) -
process-ID (with a spelled out synonymprocess-identifier`)
Then I would make PID a synonim of process-ID, just because I feel the term alone is slightly more used meaning process-ID (but that would be a judgement call. I would be OK if someone else blacklisted it).
Then in the PID-controller guidance text I would write: "Do not confuse with PID as process-ID (process identifier)", and in process-ID: "Do not confuse with PID as PID-controller".
The important thing is that an ambiguous tag should never be a "main tag", but only possibly a synonym, so that people would have the least chance of using one meaning for another by mistake.
-
For the very unlikely case that finding acceptable unambiguous terms for every meaning, I think that a call on Meta would be warranted and acceptable. These cases should be quite rare and so they should not be an issue. ↩︎
0 comment threads