Post History

## 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](https://en.wikipedia.org/wiki/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.