On a couple of occasions I have come across unwanted or surprising behavior with some widely used LaTeX packages that I have posted questions about on TeX.sX. One was about biblatex (Entry options in biblatex), the other about libertine (\pdfglyphtounicode with XeTeX). In both questions a discussion arose, and it was concluded that the behavior was due to issues/bugs with the packages themselves. In the biblatex case, one of the package authors responded that he would fix the bug as a result of our discussion.

In both cases, my questions were swiftly closed as "too localized" as soon as the notion of "bug" arose. I do not understand that policy, nor have I seen any discussion about it where such an agreement was reached.

According to Stack Exchange's founder Joel Spolsky, questions relating to bugs should not be closed as "too localized" (https://meta.stackexchange.com/a/87415). Should the TeX.sX community perhaps reconsider its (implicit?) policy on closing "bug questions" as "too localized"?

  • 7
    Related: Questions which are bug reports. – Jake Apr 24 '13 at 13:26
  • @Jake you found the same :) – zeroth Apr 24 '13 at 13:27
  • 1
    In meta.tex.stackexchange.com/questions/2622/…, the accepted answer states that in a case where the OP doesn't know that the behavior is caused by a bug, the question should not be closed as too localized. – Sverre Apr 24 '13 at 13:28
  • 1
    (Seems like we all found that question now). – Sverre Apr 24 '13 at 13:28
  • @Sverre but it was elaborated upon in the comments and hence a consensus on the issue being a bug was reached. – zeroth Apr 24 '13 at 13:28
  • 2
    @Sverre: If the issue turns out to be a bug, there can't be a correct "answer" as such (except for "It's a bug, please file a bug report"), so wouldn't closing it be the right thing to do? What would the advantage of keeping it open be in your eyes? – Jake Apr 24 '13 at 13:30
  • 2
    The fact that the issue is caused by a "bug" doesn't mean that a work-around cannot be applied. In the biblatex case, the work-around was to remove spaces. In other words, such questions can still be answerable. Closing them prevents people from finding such work-arounds and suggesting them. – Sverre Apr 24 '13 at 13:36
  • There is, nevertheless, a noticeable unsolved disagreement in the community here. The conclusion in meta.tex.stackexchange.com/questions/2622/… is that such questions should not be closed, yet they often are anyway. This discussion will hopefully resolve this disagreement? – Sverre Apr 24 '13 at 13:43
  • 3
    @Sverre In my meta question, you'll see that the answer from tohecz doesn't really directly cover the case where the author is active on TeX-sx and fixes the bug. However, the implication for me is that such a question would be 'too localized' as the solution will be 'this is now fixed in the release version: update'. Also note Martin's answer there, which covers this pretty clearly. – Joseph Wright Apr 24 '13 at 14:32

It seems to me that the practice may have outstripped the previous consensus.

I understand that (as the original meta question posited) a question that is a bug report should be closed. Truly that is not because it is "too localized" but because it is not really a question: "I've found this bug" is a statement, not a question.

The question "Why am I seeing this (unexpected) behaviour?" is a real question. The fact that the answer is "Because of a bug in foo.sty" doesn't make it any less of a question. Nor is it (as such) "localized", unless the questioner is doing something peculiar. If it's a real bug, then lots of people may be bitten by it. Moreover:

  1. There may be a way round it, which will help the questioner and possibly others.

  2. There may be no way round it, in which case it may be a reason not to use a particular package, or to prefer bar.sty over foo.sty, or something of that sort.

The original "consensus" answer linked above reached essentially that conclusion, with which I agree. "Bug reports" are to be closed because they are not questions. Bug "questions" are questions, and they are not as such too "localized": a bug is as much part of software's predictable behaviour as anything else, and unless it has already been fixed it cannot be said to "very tiny geographic regions or vanishingly small periods of time". Some bugs persist for very long periods. We need to be careful not to regard as "too localized" any question which is not of long-term general interest: judged by those standards, remarkably few questions would pass muster.

I believe that it is a "red herring" to point out that in this case the bug was about to be solved. That doesn't make the question localized, so much as the answer. Questions are often solved, sometimes "externally" (e.g. by someone writing a new package, or adding functionality to an existing package). They shouldn't then be closed; the answer should be updated.

Experience suggests that many users soldier on for months -- years, even -- with out-of-date packages. In many ways that is a tribute to the stability of LaTeX. But for such users event an answer which says "This behaviour is a bug in version 1 which is fixed in version 2" may be just what they need, perhaps months later: it will tell them that they can solve their problem by updating their package.

Indeed, the only time I would close a bug-question as too localized is where the bug has already been fixed and the questioner is only seeing it because of a failure to update. That, it seems to me, really is a case of a question which is of no conceivable general interest.

In summary:

  1. I would close bug reports not as "too localized" but because they are not questions.

  2. I would not close a question which asks for an explanation of unexpected behaviour, even if that behaviour is the result of a bug, and even if the bug is about to be fixed.

  3. But I would close as "too localized" a question which is the result of a bug that has been fixed a reasonable time ago, where it is simple "user error" in using an obsolete version of the package.

I think those principles actually reflect what seemed to be the consensus last year. Whether they were correctly applied in these particular cases, I don't know. It's inevitable that some questions will be improvidently closed, of course.

  • 2
    I couldn't agree more with what is being said here. – Sverre Apr 24 '13 at 18:29
  • I like this one too, particularly the distinction between a bug report and behaviour that ultimately turns out to be due to a bug. I've lost count of the answers that I've written starting "This appears to be a bug in XYZ. Until it's fixed, here's a work-around.". – Loop Space Apr 25 '13 at 10:17
  • Since this answer has the most votes, is the one I personally prefer, and is the one most in line with the conclusion reached in the similar question meta.tex.stackexchange.com/questions/2622/…, I'm gonna make this the "accepted answer". – Sverre Apr 25 '13 at 11:54
  • I agree, but I think a bug question that talks about a bug that was in just one release of a fast-changing package and that was never adopted by any Tex distribution is probably too localized - does it really help the Tex community to advertise these issues as living questions? It'll still be interesting if the question narrows down the wrong behaviour to a snippet of *tex code and asks for an explanation of what is going on, or something like that. – Charles Stewart Apr 25 '13 at 15:26

Quoting from Joel Spolsky's answer:

Why is there a green Honda Civic parked out in front of my house?

This is too localized because:

  1. Who cares?
  2. Is it even still there? Go check.
  3. What are the chances that this question could ever be answered in a way that would benefit anyone else?
  4. Now is it there?

In order not to be too abstract, let's examine the two questions mentioned.

The answer to the first one (Entry options in biblatex) has an answer that says

It's fixed in biber 1.1

Since we are at biber 1.5 (and 1.1 was already out when the question was posed) I'm very inclined to say that it's too localized: just updating the TeX distribution will solve the issue. We are in case 2 of Joel's answer and perhaps also in cases 3 and 4.

The second one (\pdfglyphtounicode with XeTeX) is different. The problem is about recognizing a particular ligature in "copy-paste" with a particular font.

The problem is partly in the libertine package that enables by default that ligature, but mostly about a bug in the font, that misses something in its tables that makes it possible to recognize the ligature just like ff and others are. Another one that doesn't get correctly recognized as a ligature and is enabled by default is "Qu". And, apparently, these ligatures can't be turned off unless one loads the font with the -liga option (Ligatures=NoCommon), which disables also the f ligatures.

There is no possible answer to this question other than "it doesn't depend on XeTeX, disable those ligatures and complain with the font developer". Maybe it's not "too localized". We may possibly decide that such questions should not be closed, but provided with a CW answer: closing as TL exposes it to the risk of being removed.


The reason such question are often closed it that bugs which will be fixed soon make the question "too localiced in time" because soon they issue will be gone and there is no suitable answer beyond "update the package".

Note that our "no bug questions" policy is (or should be) IMHO mostly about questions which directly cover a bug, like "why do I get this error with my MWE" (example). This is clearly a form of bug report and these should be sent to the package author either using the package bug tracker or by email. This is important because the package author might not see the question otherwise, even if (s)he is an user of this site. Also, it's not the task of the TeX.SE community to fix package bugs. Therefore I would close such questions also as "off topic". Bug reporting and fixing is simply not the topic of this site IMHO.

If the same question would be simply phrased as "how to I achieve X" and includes a MWE which shows the previous effort and mentions the resulting issue with it (i.e. the bug) then the question is very well answerable, because it allows for alternative solutions and workarounds. Then it's not about the bug but about what the user tries to achieve. (Compare: XY Problem)

  • What is the task of the TeX.SE community? – Qrrbrbirlbel Apr 24 '13 at 20:12
  • If the bug makes it to a major Tex distribution, it will be many years before people stop using the buggy package, and so it will be many years before it can truly be considered fixed. I saw someone have a problem with a bug in a Tetex package last year... – Charles Stewart Apr 25 '13 at 15:28
  • @Qrrbrbirlbel: I didn't liked to suggest that their is a dedicated task for the TeX.SE community, just state that bug fixing isn't it. – Martin Scharrer Apr 25 '13 at 16:27
  • @CharlesStewart: It takes about 2 days after uploading a new package version until the package can be updated using the TeXLive updater. MikTeX should be similar. I can't help the people which don't update their package or use a version of TeXLive which doesn't allow for that. – Martin Scharrer Apr 25 '13 at 16:29
  • 1
    @MartinScharrer: As a reason for not helping the qner, this is fine. But the text for too localized reads "This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet" - this is something else that does not apply. – Charles Stewart Apr 25 '13 at 17:21

Just to stir up the soup. I agree with Alan Munn on this issue but with a slightly different motivation. I'm actually quite bothered by the word swiftly. I don't mind if the question stays open or closed, either way the issue is not resolved so no need to insist on practice because next year it would really be an ancient issue but as you can see it's reopened after a meta discussion. Same can happen in the chat room too.

So Joel Spolsky might have a different view maybe. But he is not in this community. I would not try to learn how to socialize from Mark Zuckerberg either just because he founded Facebook. That would actually be quite a disaster. Therefore invoking rules in the discussion would make the matters only worse because then everyone starts interpreting a rule that was not there in the first place. It's a community not a state. Everything is based on interaction. I wish the use of subfigure ends tomorrow but it doesn't. That's why every time a subfigure question comes we paste the same old comment

See subcaption vs. subfig: Best package for referencing a subfigure

Now my main problem with the treatment of your question: I claim that TeX-SX community should reconsider this reviewing button habits just like we dumped the idea of downvotes. Thanks to that we didn't have any major conflicts due to why is this downvoted? stuff for quite a long time.

We cannot look for fixed rules when interacting with people. Everybody should keep in mind that it's not our forum even if we were here from the beginning. So we don't deal with customers. They are maybe experts on something completely different but not so experienced in TeX. So rule based handling feels like Microsoft Online help system. Hours of nonsense without actually getting any answer and seeing the same old

Was this page helpful? Yes No No dammit no!

Moreover, you bring any set of predefined rules and I'll find a question that doesn't fit in any cases. I'm not invoking Gödel-ish inconsistency. I'm talking about actual social setting. We don't own here. Everything is based on mutual agreement.

We tend to do things in certain way but they are not conclusive, only suggestive. In case of ambiguity, we reopen the question even if it is against the common practice because some user needs information. We hang out here for a better understanding and fun. Not because of some set of rules and discipline. Hence we do lots of mistakes until someone comes along and warns that the question should not have been closed in the first place. Then we open it again. If another one comes and warns that it's then a duplicate of another we close it again after consulting the OP.

The reason for the hostility of other SE sites, is precisely due to this behavior. Flagging, closing questions without interacting with OP. Then OP gets angry asks for reopening and composes pages long of comments and gets twice as much of belittling and accusing comments back etc. We don't do that. It doesn't cost us anything to have an unresolved question so leave it open. We handle things in the Answer the Unanswered sessions. So just move on to the next one.

Having said that, the new review system actually encourages making mistakes during closing because of those stupid yellow/red dots under our avatars :). So I'm asking our high-rep users to use it less often to close the questions. If there are two closing votes it practically means five in a couple of minutes because of our good-willed but slightly impatient reviewers. There are no machines which review questions though some of us are indistinguishable when they are editing/retagging/archiving :).

Thus there will be mistakes/misjudgements etc. a lot. This doesn't mean that we need to make the rules stricter. Instead we need to watch for the pattern how these mistakes are being generated and as far as I can see it's the review system and too much respect for common practice instead of using them as guides. A disciplined community does not mean a thicker law book that handles unambiguously every case.

So consensus is good but that's it, just a consensus.

  • 5
    I agree with this. The 'piling on' syndrome that occurs with close voting has a similar flavor to that of downvoting. We've managed to suppress the latter, now we should wrk on the former. – Alan Munn Apr 24 '13 at 23:17
  • 3
    I like this one too. One of the key points is that consensus doesn't mean we all do the same thing, nor that we always get it right. There are lots of opportunities for folk to say "Hey! That shouldn't have happened.". One of the strengths of this site (I think) is that when that occurs we don't get all defensive but rather try to understand what happened and resolve the situation. – Loop Space Apr 25 '13 at 10:19

One of the advantages of the Stackexchange model is that there are ways to discuss and in fact reverse most decisions made by the community. It seems to me that if a case can be made on an individual question that it should be reopened, the threshold for reopening is not so high that it's very difficult to do. And we have the meta site for exactly this sort of discussion. In the cases you mention, I think that the font question shouldn't have been closed, but the biblatex question should have been.

So rather than reverse a (fairly well discussed) policy on the basis of a smallish number of questions, we should instead deal with the exceptions on a case by case basis.

  • 1
    A reasonable solution here might be to include a short phrase about "bugs" in our FAQ tex.stackexchange.com/faq#close. The message that pops up when a question is closed is "This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation", which I feel doesn't pertain to bug issues at all. In my cases, it only caused raised eyebrows, since I couldn't see how the questions were "extraordinarily narrow" in time or space. – Sverre Apr 24 '13 at 14:52
  • 2
    @Sverre 'We' (the mods in this case) can't edit that text: it's network-wide. The mods have been warned of upcoming changes to the closure reasons available: I'll see if I can get more detail. – Joseph Wright Apr 24 '13 at 15:14

Ironically, having just read through the answers and left a couple of comments, I headed over the main site and found Error message with hobby package which is essentially a bug report on the hobby package (which I maintain) and which has already been fixed.

I would argue against closing this one because:

  1. The questioner doesn't know that it's a bug.
  2. Although there is a new version on CTAN which fixes it, it'll be a while before this is in TeXLive due to the freeze so there is a reasonable time frame in which others might encounter the same problem.

So although the answer (update the package) is not eternal, it feels that it will be valid for long enough that the question is not too localized [sic].

  • Very sensible. I wouldn't either: it is a question: the questioner is not announcing "Hey, I found this bug", but "Ugh, I got this message -- what's up?" which is a real question. And the answer is not "too localised" because the questioner is using a reasonably current version of software which will remain reasonably current for some time so others may well be in the same position for a while, and your answer gives useful information. Eternity is not the measure. In the long run, we're all dead. – Paul Stanley Apr 25 '13 at 10:56

I think this is related to personal preferences. A community driven site typically reaches an equilibrium in determination of how to cast votes. On this site I have seen (and been a part of) closing questions which where bug-related. In this regard see the discussion in: Questions which are bug reports.

This, as you suggest, might have been inadvertently wrong. But for this community a common ground has been reached as such. It would be very wrong to have strict same guidelines on all SX/SO (I can never tell the difference) sister sites, although a general rule-scheme should be enforced.

I think this is mainly due to the fact that TeX bugs (which are solved) are very quickly made publicly available on CTAN. Hence, the usual software long-term release are not really an issue in the TeX community (of course there are exceptions, and package-authors which have disappeared etc.). Hence the question very quickly will become invalid.

On your question about fonts. I closed it as being a too localized due to it being a font problem (not TeX/LaTeX). More correctly it should have been closed as off-topic, in my opinion.

  • Wrt the font question, this is not clear given that the font in question is typically loaded as a LaTeX package (libertine), and that ligatures are set with an option in the preamble. It is, on other words, directly related to LaTeX, since this wouldn't arise at all in e.g. MS Word (where ligatures aren't automatically implemented). – Sverre Apr 24 '13 at 13:33
  • 2
    But the ligatures are implemented in the font. And LaTeX does not "create" the ligature. (maybe I am totally wrong here, but this has been my impression). So as @egreg writes in his comment, "a bug in the font". – zeroth Apr 24 '13 at 13:37
  • We disagree on this. If a "bug" is caused by a LaTeX package (libertine) and not by "LaTeX itself", I will consider it on-topic, as questions pertaining to LaTeX packages are on-topic. – Sverre Apr 24 '13 at 13:43
  • 1
    I understood that the bug was not related to the package, but to the font. Hence the TeX package is not responsible. Are you sure that the bug is in the package and not in the font? – zeroth Apr 24 '13 at 13:50
  • 1
    No, I'm sure you're right that the issue resides in the font. But when the whole purpose of the LaTeX package is to load that font, pointing out an issue with that font would not be off-topic on a site that discusses LaTeX packages. – Sverre Apr 24 '13 at 14:46
  • I disagree. If it was, then your question should be duplicated on OpenOffice/LibreOffice/<insert ligature enabled font displayer>, which just obfuscates the real problem, I can see your side, that it could be beneficial if others had the same problem. But I will still retain the position that the question should be posed at the font-creator. I have also encountered some bugs in software which I use for TeX (but I hardly feel this will be related to this site). – zeroth Apr 24 '13 at 15:02
  • According to egreg's comment to that question now, the problem is not caused by a bug in the font, but by something in the way XeTeX or xdvipdfmx operates. This illustrates at any rate that it's premature to close a question as soon as someone identifies the problem as a bug (because it might not be). – Sverre Apr 24 '13 at 18:50

You must log in to answer this question.

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