3

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 ?

| |
4

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.

Your fill-paragraph example is very good here, fill-paragraph and 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 filling or text-filling.

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. isearch, fill, indent, 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. – Jonathan Leech-Pepin Sep 26 '14 at 13:28
  • Tagging by package is a little trickier in some cases. powerline vs smart-mode-line, smartparens vs paredit. In some cases it may be package specific, in others it might be simply modeline or parens-matching that would be a better tag. – Jonathan Leech-Pepin Sep 26 '14 at 13:33
  • @JonathanLeech-Pepin yes of course. Only tag by package when its package specific. – Malabarba Sep 26 '14 at 13:35
  • For meta-packages (such as org), do we want to keep it to something like org or allow for org-babel,ox(org-export), etc when referring to subsets of the entirety? – Jonathan Leech-Pepin Sep 26 '14 at 13:37
3

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 syntax-highlighting and 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" autoload and require have specific meanings and are terms that users will use to narrow searches. These are not like fill-paragraph and fill-region. (And I agree that a fill or filling or text-filling tag is generally more useful than those individual fill-* function names.)

Replacing the rich, meaningful, specific, well known, and easily confused terms autoload and 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 autoload and require in favor of the more general, more "behavioral" tag libraries.

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 filling, 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. – Gilles 'SO- stop being evil' Sep 28 '14 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. – Gilles 'SO- stop being evil' Sep 28 '14 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. – Drew Sep 28 '14 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. – Drew Sep 28 '14 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 require and autoload should 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. – Vamsi Sep 28 '14 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. – Drew Sep 28 '14 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. – Malabarba Oct 8 '14 at 9:11

You must log in to answer this question.

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