Help people file useful issues

[anthonyvdotbe]

While coding I've bumped into plenty of issues. However, it's unclear to me how to file a useful issue, i.e. one that will help the developers of this extension actually reproduce and fix the issue.

A good first step would be adding issue templates that explain what's needed.

Ideally, the extension would have a "flight recorder mode". If you'd run into an issue then, you'd just upload the flight recording and the developers would be able to replay it to reproduce the issue.

For example, here's a screencast of a strange bug (VS Code 1.83.1 with extension 1.0.0), the kind which is annoying and should be fixed, but which is also likely to be very hard to reproduce:

Recording.2023-10-27.171825.mp4

[anthonyvdotbe]

NetBeans used to have (I think it was removed with the move to Apache?) an exception reporter, which I really liked: it didn't take much time/effort to report issues, and the reports typically contained sufficient information for the developers to be able to fix the issues.

[anthonyvdotbe]

@delabassee I must say I'm disappointed by the governance of this project.
The extension was launched with, in my experience, a lot of issues. And I can't imagine that e.g. #49 wasn't already known before the launch. It was one of the first issues I bumped into, just working on simple Maven projects with recent JDKs.
Nevertheless, I made an effort to file issues for the most annoying bugs I ran into and also filed this issue for improving issue-reporting. However, to then see issues closed because they're not currently planned (#45) or because they're not reproducible (#66, #70) is frustrating (especially the "Thanks!" in the latter too is improper, imho). I understand it can be extremely hard to debug issues without steps to reproduce, but I'm sure you also understand that it takes effort on the users' part to stop their coding, try to assemble as much information as possible, and file a proper issue. So to help both developers and users, I believe this issue should be a top priority, such that filing issues becomes trivial for users & debugging issues becomes feasible for developers.

[lahodaj]

So, my personal opinion (and I may be overly pessimistic).

With "telemetry for bug reporting", there are two parts, a) whether the data can be collected, and b) which data (and when) to collect. I am not going to comment too much about a), but I think at least some issues in that direction are obvious.

Regarding what data to collect, I think that is a fairly difficult problem - in particular for general help with bugs, it is not clear what should be recorded, and when the recording should start. Because the problems are often quite diverse, and it is not rare that the real problem happened long before the user observes the consequence. Actually, for the video at the beginning, the problem likely already occurred, and the observed behavior is just a consequence of an already broken state. (Sometimes, it is possible to infer the cause looking the broken state, sometimes it is not - the latter being more common, in my experience.)

There were "telemetry for bug reporting" facilities inside NetBeans, like the aforementioned exception reporter.

Specifically, on exception reporter, when I was analyzing reports from it, I usually was trying to analyze the stack trace, and if that failed to give clues, the user's comments. I.e., it was useful to some degree for both the reporters (given how easy it was to report the problem), and to developers. But, reporting an issue manually does not seem prohibitively more difficult to me. And, for manually reported issues, it was much more likely to get additional information if/when needed. (And there was a significant infrastructure behind the reporter, it certainly was not that every time the user clicked on report, a new report would be created in the database - the exception reports were coalesced, etc.)

There was also the auto-profiler, which was automatically activated when the UI was stuck. It was also useful to some degree. (And also had significant infratructure, I believe.)

But, none of this was general "help with reporting general bugs". For general bugs, it is not even clear what exactly should be recorded (as we would need to know that ahead of time, before even analyzing the issue description).

Overall, I suspect the cost of creating and maintaining an infrastructure like this may be quite big, and the help with issue resolution may be lower than expected.

When I look at #49, I don't think I have good clues about "Error reporting seriously lags behind". I don't think I've seen that for the extension (but I admit my use of the extension for large-scale project is limited so far), but I use NetBeans for a fairly long time for fairly big projects, and while there are issues sometime, I would not describe them as "Error reporting seriously lags behind". Which does not mean the issue does not exist. It just means I don't have a good hypothesis what could be the cause, and don't know how to reproduce it. It is possible some piece of telemetry data would help - but I don't know what data would that be. There's certain (probably small) possibility that it is a consequence of apache/netbeans#6690 , but it is really hard to say. (There's a certain possibility that the problem fixed by that PR may be a cause for other problems you see, as the NB Documents were never intended to contain \r\n, but it is unclear so far - I didn't experiment with that much yet.)

[anthonyvdotbe]

Thanks for your thoughtful response, much appreciated.

Reporting an issue manually is indeed not much more difficult. However, figuring out how to reproduce it is. Sometimes there's a stacktrace in the log, other times there's nothing there. And even if I'd zip the whole project and share it (which I don't always wish to do on a public forum like here), it wouldn't necessarily mean that you'd be able to reproduce the issue.

I understand there was significant infrastructure behind the NetBeans reporting facilities and that the ROI is considered too low to do the same for this extension. On the other hand, I don't feel inclined to spend effort filing issues when they'll be closed as cannot reproduce anyway.

Either way, I think it would be good to add issue templates, to ask for useful information and to set expectations (by mentioning that issues without steps to reproduce are likely to be closed).

[robaho]

Encountering the same. I was so hopeful for a Java plugin by the stewards of Java - but it is very buggy. Worse, it seems to be a side project at Oracle with no people dedicated to making it happen.

Netbeans lost to IntelliJ and was deprioritized - handed to Apache - this seems like another low involvement effort.

Bummer