How to report bugs?

Question

How to report probable bugs or quirks to WRI? What is the standard way to do it? Is there a known list of bugs maintained by WRI? Can we track the status of bugs anywhere?

Answer 1

Bugs should not be reported here on this site. If you know that it is a bug, don't post here, contact WRI about it instead ([email protected]).

Questions about how to work around bugs are welcome though.

(I added this information in the bugs wiki a while ago.)

---

Note: Please don't use the bugs tag for new questions. The idea is that this will be added to questions when the problem is confirmed to be a bug (based on e.g. community consensus). This tag can be useful for many reasons (being aware of problems and knowing how to work around them---I found myself searching MathGroup for some old bug several times to make sure my code won't be affected by it), but we'd like to avoid new users reporting bugs here or adding this tag to problems they think are bugs but really stem from misunderstandings.

Answer 2

Bug Reporting Revisited

Given the way the March 2018 post of Nasser (169209) has been received (high upvotes, discussion about bugs to be used, close votes because of an essential "WRI technical support issue", chat room accusations and allegations :) ) has triggered my reflection on the accepted answer above, given by @Szabolcs.

I would beg to differ with that answer and would like to provide some arguments. There are reasons pro and con having bug reports here on M.SE and I would like to start with the obvious cons.

Contra Bug Reports

I see these three reasons given against bug reporting on M.SE:

• Dead-ends By reporting bugs here, they never reach WRI and users will get lazy to report them, since they feel M.SE to be a viable substitute for the "real thing".
• SE-incompatibility By leading to lengthy and controversial discussions they are not a good fit for the Q&A-rules of SE. Also they often might get closed due to "technical issue for WRI or professional help".
• Better Places Incompatibility for SE immediately suggests there may be "better places" for bug related discussions; often Wolfram Community seems to be the natural candidate.

So let's have a look:

Dead-ends

While this clearly is a danger, keeping people from repeatedly posting an issue is also a chance (we'll be getting there with the Pros). Clearly using bugs should be a "call of civil duty" to file a report at the same time or even earlier and to provide that information clearly visible for all. Then the dead-end threat will be minimized because not seeing a case number eventually will make me file a report to be sure. And further more, seeing the issue pop up here will maybe serve as a reminder for me to report the long-forgotten issue myself.

SE-Incompatibility

Certainly discussions do not fit SE, but they are far from being banned. SE's main interest is to make money from its users and their knowledge - pardon me :), is to prevent discussions from spoiling concise and useful Q&A to build a knowledge base. That is why we have chat rooms. And lengthy discussions automatically open such a room. Where is the threat?

Q&A are a perfect match for bugs: Firstly, we ask about whether we were too dumb to read and understand the documentation (not necessarily a proof of low IQ...). Then we ask whether there are workarounds or third party packages or whether there are deeper insights and related issues. The community might be interested in the scope of an issue (operating systems) and we may even in our desperation become interested in other tools and languages to provide a solution (not for long, alas).

While ultimately WRI, of course, will have the definite answer, all of the bug-related questions may well find sensible answers here in that nice and concise way, for which we love SE so much.

Better Places

Well, be honest, are there really better places than M.SE?! While to a degree Wolfram Community is decent, it does not match M.SE in quality, speed, and precision imho. A clear downside: It belongs to WRI. Here we can have anonymity and meet on neutral, third-party grounds -- which is a prerequisite often for openness and honesty. Maybe this is, why we have so many visitors from Illinois? :)

Pro Bug Reports

Speed

I hope not to be the only one suffering from a low tolerance to waiting times. But given the average time of responses here, waiting at least 24h for WRI to return with "acknowledged, you will hear from us soon" is simply not an option.

Not everyone is a premier service subscriber entitled to a decent response time.

Transparency

I firmly believe in checks and balances -- e.g. balance of power: Filing bug reports has something of David against Goliath. I am at their mercy and their good will. Making bugs transparent -- if done fairly (-> SE-rules) -- is a very powerful tool to foster accountability and to increase consumer power. It clearly shows, whether WRI considers an issue worth their efforts and it shows, whether we are alone in our requests.

Given the technological dependencies and the recent "breadth vs. core" developments, the last issue is an important one. M.SE transparency will help me manage technological risk far better than simply watching for marketing output nobody with interest in truth turns to anyway...

Efficiency

If used wisely, both sides -- WRI and users -- may profit greatly from this sites' format: Its rules foster concise and useful bug-reports (at no cost for WRI! -- believe me, their showing up here is no coincidence ...). SE works like a filter, thus irrelevant, long-known issues are not flooding the pipeline. It also clearly and quickly shows the interest among users in an issue (again anonymity and speed!).

Our time is also saved, as there is no public record of known issues (bug-tracker?). Instead of wasting hours in trying out and waiting for a response we will quickly see whether an issue has already been reported and for how long it is known. Then we can decide upon all available information whether to also file a report by referencing to the known and published Case #.

Update: There is another angle to having a bug list here. Most often I read that unless many people complain by filing bug reports, an issue will not be fixed. This waste of users’ time — who after all pay for working software — can only be avoided by having a public list of bugs and case reports. In that case the number of filed reports cannot be used as a proxy for user interest any more. It seems ridiculous to me to be dependent upon a number of filed reports for having an issue fixed whose functionality was advertised to get at my money. Why?

Conclusion

I firmly believe that the pros far outway the cons. In the end, WRI and we as users, may greatly benefit from a publicly visible and useful repository of issues that are to be considered a bug. I saves time, fosters accountability and bundles the voice of the consumer while also improving efficiency on all sides.

The SE-rules work as a filter here and are imo very much compatible with bug reporting.

I would see these words of guidance:

1. If not in a hurry and you are clear about an issue being a bug, file a report first!
2. If you are in a hurry or are not clear about an issue being a bug or if you consider your reported issue of wider interest for the community, make this a good and relevant M.SE question without assigning the tag, e.g. ask for workarounds, related and deeper issues etc.
3. Wait for responses and let the community decide to assign the tag bugs.
4. If there is consensus about the issue being a bug, report it to WRI and publish the results (e.g. case opened, final answer).
5. If the issue is fixed -- you will be notified -- update the bug-header to indicate this. Also indicate the persistence of your bugs on new releases.

Answer 3

I saw Sjoerd removed the bug from this question, so I came here to see what the points of view are. To be clear: I agree with the removal of the tag since it's not a confirmed bug.

On the other hand I would like to have some tag indicating that OP suspects it's a bug. That's the core of the question, not "notebook" as it is tagged now. But it's only indicated in the title, which IMO is not the right place.

I'm for a bug-possible and a bug-confirmed tag. The first one is a better indicator of the status than simply bug, and I would feel invited to test OP's code to see if I can reproduce reported behavior.

When to switch from bug-possible to bug-confirmed? How about: when the behavior is confirmed for the same Mathematica version by at least 2 (or 3?) other users?

I would incinerate the bug tag.

edit (re Mr.Wizard's concerns)
I don't see the problem with neophytes using the bug-possible tag when it's no bug at all. If it is because he doesn't seem to understand how Mathematica works it can be explained in a comment or answer and the tag removed.