29

From time to time we get questions which are due to clear bugs. In some cases it may be possible to suggest a fix: this is most likely for macro code. On the other hand, some of these questions are essentially impossible for us to work around, particularly if they are bugs in binary material such as editors.

I think it's important that we have a position on when these questions should be left open, and when they should be closed, and also how they should be closed.

3 Answers 3

Reset to default
28

After some discussion in the chat (link) I guess I can re-formulate the answer:

Case 1. User clearly knows that it is a bug. Then the question should be closed as not a real question.

Case 2. User is not aware it is a bug. Then he really wants to find a solution. In such case, I believe that the answer:

This is basically a bug in the package/program and as such, it should be reported using the way explained in its manual.

is a legitimate answer to the question. I think that unless you can be sure that a package author corrects the bug soon (e.g. because he's active here), the question need not to be marked as too localized.

6
  • If the OP doesn't know that it is a package bug then that's fine, but sometimes people post direct bug reports ala "I found a bug in package X".
    – Martin Scharrer
    Jul 8, 2012 at 18:09
  • 7
    "I found a bug in package X" is definitely not a real question.
    – yo'
    Jul 8, 2012 at 18:09
  • I agree with tohecz; of course the question should be a real question, not "this is a bug, period". I'd add in the answer the recommendation that the OP edits the question when the bug is solved.
    – egreg
    Jul 8, 2012 at 18:28
  • 9
    There is also case 3: User knows that it is a bug and asks for a workaround.
    – Caramdir
    Jul 8, 2012 at 20:11
  • 4
    @Caramdir: In that case I'd suggest posting an answer with a workaround, while also encouraging the OP to file a bug report and link to that in the question (or, if applicable, link to an existing bug report).
    – Jake
    Jul 8, 2012 at 21:52
  • @Caramdir: I agree. More often than not, a workaround is asked for -- a fix, even if timely, still is often too late to be useful for the OP.
    – krlmlr
    Mar 29, 2015 at 11:46
20

Bug reports about (La)TeX packages etc. should not be posted on this site, but reported to the package author using the method (e.g. email address, bug tracker) given in the package manual. Because the bug might be fixed in the next version of the package, the "question" is IMHO "too localized" in time and should be closed as such with a note that bug reports should not be posted.

As an author of several packages I always find it strange when bug reports are posted on comp.text.tex, here or a different list or place, but the same person doesn't bother to contact the author directly. That's not really the way to do it. First, the author might not see the post, because he/she doesn't read the site or list, at all or just not that day. Second, it's much easier to track issues using an specific email folder or bug tracker, than to have the reports all over the Internet. Finally, I don't find it good behavior to not include the author explicitly while posting issues in public.

This is for direct bug reports. Posts about issues with packages which are not easily recognizable as bugs, but turn out to be bugs during the solving process, are a different matter. Then a workaround with a request to contact the package author might be a good idea.

4
  • 12
    i agree that bugs should always be reported to the author (or maintainer) of a package. however, in some cases (e.g., ams classes and packages) it is known that the bug, although documented and on the "repair" list, will not be fixed soon either because of policy (including the necessity of maintaining an active "long-term" production stream) or lack of resources. in such a case, the information that something is a known bug is useful. in the absence of a publicly available bugs list (such as the one for the latex project), i don't see a problem with keeping a relevant question open.
    – barbara beeton
    Jul 8, 2012 at 12:59
  • 3
    There is also the area of packages which are no longer maintained: there, a public statement may be the only way forward. Then again, this at least needs to be phrased correctly.
    – Joseph Wright Mod
    Jul 8, 2012 at 15:28
  • 9
    There are also many questions, where it isn't immediately apparent to the OP that he encountered a bug. In that sense they aren't really bug reports.
    – Caramdir
    Jul 8, 2012 at 15:32
  • Long comment to your answer posted as an "answer".
    – Peter Grill
    Oct 29, 2012 at 5:44
11

This is more of a comment to Martin Scharrer's answer (Case 2 of tohecz's answer), but too long for a comment...

While I can't disagree with anything in Martin's answer (excluding the first part of the initial sentence), I personally would prefer that bugs be posted as a question here, even if they end up being closed. Many times it is not clear whether it is a bug or not. For example consider these two questions of mine:

One was a bug, the other was not.

Had someone else reported the same symptom I would have checked that first, and it would have saved me many hours to have to distill it down to that point. I had no idea it was related to currfile/enumitem until I was able to get it down to a small MWE. I just thought I was perhaps redefining something incorrectly that was causing this issue.

And then at that point, do I report this as a bug for currfile or enumitem? Not sure how a user is supposed to decide.

Furthermore I was thinking that perhaps there is still some corruption in my TL2012 installation as per:

Once others can confirm that they see the same behavior, and not some option clash issue, only then would it be known as a bug (except of course to the pacakge authors), at which case I would have emailed the authors.

And even if the problem is fixed in a updated version, many people tend to stick with old versions given that we often get questions where the answer is to update their distribution. Here is one form today: problem with mdframed commands. If there were question here with the same problems that those people were experiencing, then they would know that they needed updated packages and/or release.

I am not suggesting that this site be used as a bug tracking system or that all bugs be reported here, just that if one person took quite some time to narrow down to a bug, then posting it here is useful. And if an answer shows up that provides a workaround until that bug is fixed, that might be also be useful to others who do not want to update their packages/releases.

You must log in to answer this question.

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