How to reports possible bugs in Stata to Stata Corp?

[Salah Mahmud]

Does anyone know?
Are Stata corp monitoring this forum for bug reports?
Contacting technical services to report possible bugs after discussing them here does not seem practical.

/salah

[Clyde Schechter]

Are Stata corp monitoring this forum for bug reports?

There are some StataCorp employees who are members of the forum. I do not know whether they continually monitor activity or simply participate when they feel like it. In any case, I would not rely on this forum for this purpose.

Contacting technical services to report possible bugs after discussing them here does not seem practical.

Why not?

If you find something you think is a bug, it is probably best to begin by discussing it in this forum because:

1. It may be a mistake on your part rather than a bug, and somebody may be able to point it out.
2. It may be a known bug for which a fix has already been issued and somebody may be able to point it out.
3. It may be a real bug, and others may reproduce it on other operating systems or versions--knowing which OS's and versions are affected by the bug can be helpful.

Then, if it is a bug, I would contact technical support at StataCorp. I have found that they are always quite responsive.

[Salah Mahmud]

I agree that is valuable to discuss bugs reports here, because often they are not. But having an additional private conversation with Stata tech support is superfluous because all the discussions, reports of reproductions, etc are already posted here. Most software companies now use a developer-oriented platform, such as https://github.com or https://gitlab.com, which allows public discussion of bug reports and more importantly efficient tracking of the status of bug reports (as issues) to ensure timely fixes.

[Nick Cox]

Salah: I don't understand all your misgivings here.

StataCorp advertise how to report problems directly to them. If you need to do that, start at https://www.stata.com/support/faqs/t...-tech-support/

StataCorp and StataCorp only can answer any questions that (turn out to) concern compiled code. StataCorp do not publish this code which remains private and proprietary and by extension there is no public forum to suggest corrections or extensions to that code.

For problems that concern official commands it's often best to go to the people who wrote them and/or maintain them, usually StataCorp. That particularly concerns major commands which even when visible are implemented as substantial and complicated ado code. You won't usually know who these people are, but that is not a problem as the support people at StataCorp certainly do.

Bottom line: Statalist, however, remains the best public forum for first discussing Stata problems. I hang out on Stack Overflow and watch other forums intermittently and I think that summary is not just personal preference.

Most bug reports turn out to be bugs in the user's code or misunderstandings of how a command works, so Clyde is right as usual. Start here, but be prepared for a signal that we don't know (the signal is often silence), which implies taking up a problem with StataCorp directly.

[Weiwen Ng]

...

If you find something you think is a bug, it is probably best to begin by discussing it in this forum because:

1. It may be a mistake on your part rather than a bug, and somebody may be able to point it out.
2. It may be a known bug for which a fix has already been issued and somebody may be able to point it out.
3. It may be a real bug, and others may reproduce it on other operating systems or versions--knowing which OS's and versions are affected by the bug can be helpful.

Then, if it is a bug, I would contact technical support at StataCorp. I have found that they are always quite responsive.

I added a link here because it illustrates an instance where:

1. I jumped the gun and reported what I thought was a bug to Stata, right after making post #5 in the thread.

2. It wasn't a bug!!! I realized this a few minutes after I sent the first email. So, Clyde's advice in his point #1 is spot on.

3. Stata tech support responded quite quickly and very graciously to me via email. (After coming to the realization that it was my error, I sent their tech support a follow up email.)

4. One of Stata's statisticians even posted on the thread, and responded to a question I had.

I would like to add that I believe Stata do monitor the forum. One of their statisticians indicated as much to me at AcademyHealth's annual conference (which just concluded). They don't make a habit of posting responses, although some staff do. They also can't necessarily be aware of every problem that is discussed, because there are a lot of threads going on. The thread regarding the Stata 16 wishlist is very, very long, so that one is especially hard to monitor (and the Stata 14 and 15 wishlists were the same, and the Stata 17, 18, 19 etc wishlists will be the same).

Separately, I emailed Stata with some concerns over their implementation of latent class analysis. The tech support person passed my concerns along to their developers. Because the issues raised were quite technical and because I wasn't able to share my actual data with them, that correspondence took a bit longer and required me to follow up with them. Nonetheless, I would characterize them as responsive.

I have no experience with contacting their non-English tech support, though. I don't know if translation issues would be involved, but if they have to go through translators, that would probably lengthen response time.

Edit: Adding to my post, you can simply link them to the thread where the discussion took place, which saves you time. That's what I did in my post earlier, complete with simulated data illustrating the point.

[Salah Mahmud]

Nick,
As I mentioned above, no disagreement about the value of discussing possible bug reports here.

My point is that when something turns out to be a bug in Stata, I should not be expected to spend my time reporting it to StataCorp. I have already spent time discovering the bug, discussing it here, finding a workaround etc. I am not seeking technical support from StataCorp. I am contributing to the quality control of their product, so should not I expect that they make that contribution easier for me to make (e.g., by using the information provided here)? Even free (as in free lunch) software packages provide easy-to-use bug reporting tools to their users, because they know that improves the quality of their product and increases user satisfaction.

Also, having a github issue tracker does not require that you publish the source. You could have an issue tracker on github or gitlab without publishing your source code there.

It would be nice to hear from someone from StataCorp about this suggestion,

[Richard Williams]

I’ve seen Stata Corp respond to any number of threads by saying “X has identified a bug that will be fixed in a future release of Stata.” If a bug was found in post 27 of a thread it wouldn’t surprise me if they missed it. It would take less than a minute to email tech support with a link to a thread discussing the problem.

if I am 99% sure I have found a bug I usually email Stata directly.

like others, I don’t understand the concern. Have there been repeated problems with Stata Corp ignoring bug reports? If so I haven’t encountered them.

[Nick Cox]

Salah: Let's cut to the chase.

In #1 you asserted "Contacting technical services to report possible bugs after discussing them here does not seem practical."

It's eminently practical. I often do it.

No one is making you do it or insisting that you do.

If you want to convert a high probability that StataCorp read your posts to a probability of 1, you can spend a minute emailing a link to tech support.

Have you previously posted about a bug that turned out to be a problem in source code? I haven't re-read all your posts but what I recall turned out to be misunderstandings, not bugs.

[Salah Mahmud]

I am sorry but I will insist on making my simple point which remains: it is the job of a software vendor to develop ways that make it easier for people to report bugs. I suggested two possible ways: using github or a similar issue tracker and developing a systematic way to track possible bug reports here. Contacting technical support after posting here is not practical for me.

If people do not agree with my suggestions that is fine. But there is really no reason to be defensive or to personalize the discussion. There is never a good reason for that.

I will stop now. Thanks for your time!

[Richard Williams]

Getting back to the original question, bug reports can be sent to

[email protected]

Here is their advice on contacting them.

https://www.stata.com/support/tech-support/contact/

Other information on Stata technical services is at

https://www.stata.com/support/tech-support/

[William Lisowski]

I disagree with post #9. I feel that the job of a software vendor is to allocate available development resources in a way that best generates further development resources, and consequently product viability. Apparently Stata prefers a bug reporting system that you find impractical. Others here have indicated that the current system adequately meets their needs, and implicitly, that they prefer other uses of StataCorp's resources. Our opinions differ. De gustibus non disputandum est.

I must say that continued restatement of our satisfaction and continued restatement of your preferences is equally "defensive" on both sides - but also, I would characterize neither as "defensive", a description all too often used to characterize "having strong feelings" as are evident on both sides of this disagreement.

[Sven-Kristjan Bormann]

I have also a question regarding reporting bugs. If my question is off-topic, then feel free to move it somewhere else, but I did not want to open another thread for it.
How do you report bugs in older versions of Stata if you do not know whether they are already fixed in a newer version of Stata?
To be more precise: I found a bug/oversight in the dialog box for the teffects command provided by Stata since version 13. But I have only Stata version 14. Should I still report the bug or fix it by myself if needed?

[William Lisowski]

Welcome to Statalist.

First of all, I must say that my experience with the Stata Technical Services staff has been uniformly positive, so I would not hesitate to ask them your question.

But you could instead put the question to Statalist. In a new topic, describe the problem you see with the dialog box and ask if those with later releases have seen it corrected. Also, it is possible you have overlooked or misinterpreted something, so you might prefer this sort of confirmation before reporting the problem to Stata Technical Services. If you choose to do this, please include the first two lines from the output of the about command so we know precisely what version and update you are on. And if you haven't done so already, take a few minutes to review the Statalist FAQ linked to from the top of the page, as well as from the Advice on Posting link on the page you used to create your post.

Then there are the whatsnew files. At the time of this writing, the output of help whatsnew will show you what changes have been made to Stata 15 since its release. Scroll to the bottom of that and you can see links to earlier whatsnew help files. But this can be fairly tedious to search through.

[Sergiy Radyakin]

Dear Salah,

from my experience it is best to submit a minimal case to Statalist, which can be replicated and discussed. In most cases an explanation for seemingly strange behavior exists and is berried somewhere in the documentation, which other experienced users may point to. As Clyde has pointed out, there are a number of StataCorp employees on the forum, but if you don't get an advice from them within days of the posting and nobody on the forum points to a documentation permitting the behavior you consider a bug, just write to tech support with a reference to the Statalist posting.

Here is an example of a thread where the bug was confirmed: 930869.
Here is an example of a thread where the behavior was not a bug: 81167.
Here is an example of a thread where the support convinced me I shouldn't be doing what I was doing: 102900.
Here is an example where no opinions were voiced by anyone, and I didn't have any need to pursue the issue: 157813.

Sven-Kristjan Bormann , there are a lot of active Statalist members who have up-to date Stata installations and can assist you with revalidating your suspicions with contemporary versions of Stata. I have used their assistance many times see e.g. 1290567, and in many cases they would even volunteer to do it (many thanks!): 1452780.

Overall, posting the strange or puzzling behavior description to the Statalist forum has a positive effect of getting a fast answer from various angles, and perhaps a number of (often similarly surprizing) workarounds.

Best, Sergiy

[Sven-Kristjan Bormann]

Dear Sergiy and William,
thanks a lot for your help. I have now open a new thread about the same issue here .
I hope, I got your suggestions right.
The reported issue is nothing that bothers me. I just noticed it, went to the code for the dialog box and found the bug/omission. It should not matter too much since it is only an annoyance. That's why I was not sure if I should report it or not.