There is the GitLab issue tracker. Should bugs be reported there and not here? That is what i understood, also indicated in this FAQ-Post and this old, pre-GitLab, thread says the issue tracker (back than it was Launchpad and not GitLab) should be used.
However, there are lots of people that report bugs here , including bugs that are obviously bugs of KiCad and not user errors (such as crashes) and it takes often multiple replies till someone mentions the GitLab issue tracker.
Where should bugs be reported? On the GitLab issue tracker, here, both or does it not matter? In case bugs should be reported on GitLab, what should we do when someone else posted a bug here and not on GitLab? Just tell them to search on GitLab for this bug and create a new GitLab issue if it was not found?
Where should we post issues that we think are bugs but may be user errors instead of a bug?
If you want developers to see what you write - write there.
If you don’t want to disturb developers don’t knowing for example how to reproduce a problem - you can write here.
Of course, and most regular members know this.
As @Piotr wrote, we don’t wish to disturb developers or contributors with problems other than genuine bugs. If not certain of a genuine Kicad program bug, most will air a problem in the forum first.
We try to look after you guys. Some say we are often trying.
4 crash reports (only crash reports, other types of bug reports not counted) in 8 days. It where only the ones i found on a very fast search. In my subjective experience it is quite frequent to read bug reports here of bugs that are obviously bugs.
Most mention suspected bugs. They wait for confirmation from other members before reporting on Gitlab.
Sorry to do it this far down the thread, but I’ve recategorised this to Community, as Meta means discussions about the forum software, Discourse. Shouldn’t affect anything except the tag.
Yes, that is a bug, but is it a Kicad program bug, an OS bug, a plug-in bug, an operator bug?
Many possible bugs arrive on the forum to discuss exactly what and where is the bug. There is no point reporting to Gitlab to find the bug cannot be reproduced and the matter closed.
The crash (bug?) below turned out to be an operator error. It would have been pointless reporting this on Gitlab.
it seems to me that errors should be separated at least by platform … because let’s say on Linux there may be an error, but it is not on win and vice versa … the second point is errors on plugins, it generally turns out to be a mess …
yes, this is understandable, but the developer who wrote the plugin or the kickad itself needs to be tested on three platforms, and this, for obvious reasons, cannot always be done … even python works differently on different platforms …
I think your question raises an very important distinction . . .
Obviously what is most important to the developers is a detailed bug report with a tested way of reproducing the issue. This way they can quickly see and understand the issue, investigate the cause, prioritise it and finally fix it (hopefully).
The formal bug report takes some effort to do properly on the part of the user . . . it is really, really valuable though.
But what you are talking about is something that you think might be a bug or your misunderstanding of how to use a feature or even a problem with your OS . . . in that case you might not be able to properly reproduce the issue or even coherently describe it.
In my opinion for this kind of issue your first port of call should be to report it here. If others can reproduce it then great, others might even find an easier way to reproduce it at will, that then helps the creation of the formal bug report.
In general it’s quite simple. This forum is for users, and user questions, and gitlab is for developers and communicating with them, and thus also for bug reports. But the world is not so straight forward.
When there is doubt about a (possible) bug, it sometimes happens that it is reported here. (It may even start as a question). Quite often users can help each other in pinning down the behavior of a bug or verifying whether some behavior is a bug at all. Developer resources are also a sparse resource of the KiCad project (they have several years of work of features to implement in future versions) and all the time they spend reading messages on gitlab is time they do not spend on writing software and improving KiCad itself.
It is a part of the workflow of Open Source projects. Users can help by tracking down and verifying bugs, and if this can be done before any of the developers get involved, then they have more time left to work on actual code. I have picked up quite a bunch of (possible) bugs here on this user forum, independently verified they actually are a bug, then searched gitlab to see if the bug was already known and/or fixed, and if not, then spend more time to write the actual bug report. Going though this process can easily take an hour or more, and the bugs I reported sometimes get fixed in less then half an hour. For me it is a part of the ways I contribute to KiCad, and I do it because I like the Idea’s and philosophy behind Open Source software.
