I am new to the tagging system here. Suppose I have a question about
load-library. Should I use
load-library as a tag or just
load as a tag ? I already see
fill-paragraph as a tag but the questions also dealt with
fill-region implicitly. So are there any guidelines on how to tag ?
I am new to the tagging system here. Suppose I have a question about
No, we certainly don't need tags for each function name.
Lots of different functions represent the same behaviour or goal, it would make no sense to have different tags for the same topic.
We should tag by behaviour.
fill-paragraph example is very good here,
fill-region both do essentially the same thing, there's no sense in
using different tags for them.
Though, personally, I would have used a tag like
We should also tag by package name, when relevant
I'd like to hear people's opinions on this, but in many occasions I feel it's also relevant to tag by the package name.
Agreed. Tag by behavior/feature.
comment, etc. They all have a family of functions that share features (and sometimes the wrong function is used so the tag would be wrong/misleading). Tag by family of functions or provided behaviour. Sep 26, 2014 at 13:28
Tagging by package is a little trickier in some cases.
paredit. In some cases it may be package specific, in others it might be simply
parens-matchingthat would be a better tag. Sep 26, 2014 at 13:33
@JonathanLeech-Pepin yes of course. Only tag by package when its package specific. Sep 26, 2014 at 13:35
For meta-packages (such as
org), do we want to keep it to something like
orgor allow for
ox(org-export), etc when referring to subsets of the entirety? Sep 26, 2014 at 13:37
This is not something that should be handled in a blanket, black-and-white, "general principle" manner. It's fine to agree that:
- "We certainly don't need tags for each function name" and
- "Lots of different functions represent [generally] the same behavior or goal..." and
- "It would make no sense to have different tags for the same topic" and
- "We should tag by behavior"
I agree with all of that.
However, there are functions and there are functions. And behaviors and behaviors. And a function implies/represents a behavior. It's not about one vs the other - especially for a language like Lisp and an extensible environment like Emacs.
Both (some) function names and (some) behavioral categories can make sense as tags. We are not just erecting a lattice of theoretical categories when we define a set of tags. We are trying to help users search. What terms will Emacs-site users think in? should be a question that informs what tags we end up with.
The idea should not be to replace useful, Emacs-specific keywords that represent important and well known behaviors with super-general, overly abstract "behavior" categories that people will not search on or that will not prove useful in practice if searched on because they are so general.
Consider the tags
font-lock on Stack Overflow. Both exist. The latter is pretty much specific to Emacs. But someone might argue that the former is more abstract and more "behavior"-oriented, and so should subsume the latter. Fortunately (IMO), SO has allowed both. They are both useful, even though, yes, there is overlap.
Here is a case in point of what I think is misguided. Emacs "functions"
require have specific meanings and are terms that users will use to narrow searches. These are not like
fill-region. (And I agree that a
text-filling tag is generally more useful than those individual
fill-* function names.)
Replacing the rich, meaningful, specific, well known, and easily confused terms
require with the general tag
libraries is misguided here, IMO. Users are more likely to search using the former than the latter. I am not against having, and using, a tag
libraries - I am even in favor of its addition to that question. I am against systematically removing tags such as
require in favor of the more general, more "behavioral" tag
In the end, this kind of thing requires judgment. And it is ultimately about what is most practical for search by users of the site. It's not only about finding high-level, abstract categories that form a nice hierarchy or that partition the search space. It's about having tags that reflect what users will use for searching.
Beyond this gripe, I find it a bit unfortunate that we are already, a week or two into Beta, editing away the tags that users apply to their questions. Some time and experience should help determine which tags are most useful - whether, for instance we should have
text-filling, or both. For now, at least, we should err on the side of giving users the benefit of the doubt when they apply and invent tags.
If a user wants to tag a question
unwind-protect, allow it. We gain nothing by removing such a tag or replacing it with some watered-down term that applies more broadly. Yes, sure, we can have a general tag such as
non-local-exits (the general term that the Elisp manual uses where it describes
unwind-protect). But we can allow
unwind-protect too. Why? Because it will be useful to people searching this site.
It's a bit early for the Tag Police to be making the rounds, applying and citing "general principles" such as the one proposed in this post. As for that principle: it's fine as far as it goes, but (a) a particular function name is sometimes the best name to represent a behavior, and (b) application of such a "rule" requires judgment. It should not be about memorizing a catechism and applying it indiscriminately.
I think I agree with having require and autoload as tags — they're important sub-topics of libraries, and so worth a tag in their own right, to distinguish them in searches from incidental use in code snippets. Sep 28, 2014 at 3:19
On the other hand, I strongly disagree with your “tag police” remarks. Now is very much the time to worry about tags. Establishing key tags and tagging policies is a goal for the early beta. It's easier to enforce consistent tags when there are 3 questions to retag than when there are 300. Tags need to be consistent and discoverable, not inventive. Sep 28, 2014 at 3:22
@Gilles: Again, it is not about applying a general principle in a blanket way. This is the most important part of that goal you cite: "The best way to identify tagging problems is to watch new posts closely, and try to build tag wiki excerpts that explain what the tags are for. When tags become ambiguous, too specific (or not specific enough), or just somehow off, raise those issues in meta, and quickly. Proper tagging is very much a lead-by-example activity." That was exactly my point: "Some time and experience should help determine which tags are most useful." Build tag wiki excerpts. Sep 28, 2014 at 3:28
@Gilles: And raise those issues in meta refers, IMO (I hope) to raising issues about specific tags, not just to abstract discussion of principles. Lead-by-example activity is right on, IMO. Sep 28, 2014 at 3:32
1@Drew My question was intended to get a clarification on what is considered best policy (making it easy for users to search) rather than stipulating rules on potential tags. I do agree that having
autoloadshould be independent tags for the same reason popular/specific packages should have their own tags-Create a taxonomy of relevant questions on important topics. But there seems to also be a consensus in not trivializing tags by assigning all functions their own tags which was what I wanted to clarify.– VamsiSep 28, 2014 at 4:23
@Vamsi: I agree, particularly about "not trivializing tags by assigning all functions their own tags". My main point is that this kind of thing requires not just rules but judgment, and often case-by-case judgment. And it's OK that judgments differ and any of us can judge poorly sometimes. There is no silver bullet for this kind of thing. Any rules here can only be rough guidelines, IMO. Sep 28, 2014 at 15:49
I agree with everything you said before the last paragraph. We do have to come up with general principles now, so that later we can perform retagging without having to resort to a meta question every single time. General principles are not Rules. They guide our choices, they're not absolute nor irrevokable. Oct 8, 2014 at 9:11