Golang has this feature and I think it is convenient as it starts a new bug report with some system information (version of the binary, OS version and more).
The command is used typing go bug
. We could define godot bug
or godot report
.
Here is the file where the feature is implemented in Golang: https://github.com/golang/go/blob/b7d3f4c0b2f421c6b7bf6ce3533f1b34b470b39d/src/cmd/go/internal/bug/bug.go#L40
I think this is quite a bad idea. Because making the process of raising an issue simpler means that we are going to have a lot more issue to deal with, which are more likely to be poorly written and to miss informations.
We already have a limited amount of human resources, such issues would not be welcome.
In general, I don't think we want to simplify the issue submission too much, so that people creating issues get really involved in the processus. It is the same reason we do not want automatic reports when Godot crashes. But @akien-mga could confirm I guess.
I don't think it is very different from opening the issues and clicking the "New issue" button which is already very simple.
If someone wants to create a low effort issue they will do it anyway as github makes is really easy. In fact, this could improve the quality of the reports as it could automatically include information which is missing in a lot of reports and sometimes is important for context.
It's not about making bad use easier, it's about easing the experience of reporting bugs automating the addition of system information.
If we keep it a terminal only feature I don't think a lot of people will abuse it.
I'm against having tools that report bugs in your place (i.e. you type a command or click a button and a bug report is created, without you ever visiting github.com).
I'm ok with adding tools that can load github.com in your browser with the issue template pre-filled with relevant information, and where the user would need to finish completing relevant stuff (description of the bug, backtrace, GIF, etc.). Or just a tool that could extract copy-pastable system info would be just as well IMO, then we don't need to bother with the GitHub API.
The reason I left the up vote on the original proposal is, if we had a command that would let people make a report (since it's commandline, it'd be mostly reports that Godot doesn't work on their system), we could have a list of bad drivers that require GLES2 and -- maybe -- make Godot switch to GLES2 automatically.
For instance, I'm currently down to Intel HD 3000 and I find myself forgetting and trying to launch Godot only to get mad because it doesn't (not using 3.1 yet because well, it's not for production)
go bug
doesn't create the issue, it just opens the browser with a new issue template with the system information.
In case of a failed request to "https://github.com/golang/go/issues/new?body=" it prints the body so you can copy paste it in a new issue:
https://github.com/golang/go/blob/b7d3f4c0b2f421c6b7bf6ce3533f1b34b470b39d/src/cmd/go/internal/bug/bug.go#L65-L69
Would it make sense to implement this as a command-line argument, considering most Godot users don't use the command-line interface often (if at all)?
Self-quoting:
if we had a command that would let people make a report (since it's commandline, it'd be mostly reports that Godot doesn't work on their system), we could have a list of bad drivers that require GLES2 and -- maybe -- make Godot switch to GLES2 automatically.
@Zireael07 I think the Godot project manager automatically fallbacks to GLES2, but the project creation dialog won't choose GLES2 in new projects automatically if your hardware doesn't support GLES3 (which causes various issues).
I seem to remember cases where some drivers claimed to support GLES3, but in truth didn't and various issues happened as a result?
@Zireael07 From what I've seen, Godot will still start on such drivers, it will just be broken in various ways (e.g. GPU particles not rendering). Still, I don't think beginners are going to use the command-line interface for this – some of them don't even know how to open a command prompt.
Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!
Most helpful comment
I'm against having tools that report bugs in your place (i.e. you type a command or click a button and a bug report is created, without you ever visiting github.com).
I'm ok with adding tools that can load github.com in your browser with the issue template pre-filled with relevant information, and where the user would need to finish completing relevant stuff (description of the bug, backtrace, GIF, etc.). Or just a tool that could extract copy-pastable system info would be just as well IMO, then we don't need to bother with the GitHub API.