I have been wondering if questions that have the character of a bug report or lets say questions about locating, fixing or working around bugs of certain packages in certain environments are welcome to this site?
I recently posted one of those questions myself that can be found here and works as en example of what I mean.
I don't see why not. Of course, this site shouldn't be used to actually report bugs. Those should be reported using whatever bug tracking system the relevant project uses, but asking for a workaround is fine.
In any case, it's often hard to know if what you're facing is a bug or a misconfigured system. Perhaps your issue with your user being logged out on suspend can be fixed by toggling a setting and isn't actually a bug.
So asking such questions seems fine to me.
Off-topic: “When I do X, Y happens. It shouldn't. Fix it.” (Even if you happen to know that the maintainer hangs around here, this is not a bug tracker.)
Off-topic: “When I do X, Y happens. It shouldn't. How can I fix the offending program?” (This is not a programming site, and even on a programming site, this is only ok if the bug has been narrowed down to a small piece of code that is included in the question.)
Off-topic: “When I do X, Y happens. It shouldn't. Has this bug been reported yet?” (This is not a search engine. That being said, it can be hard to find where to report a bug, but chat is more appropriate if you need help there, because it isn't easily transferable to other people.)
On-topic: “When I do X, Y happens. This is surprising because I expected Z. Why does Y happen?” (And if Y turns out to be a bug, so be it.)
On-topic: “When I do X, Y happens. This is obviously a bug [e.g. because it's a crash]. Given …, how can I work around it to do Z?” (The question should of course make it obvious why “upgrade to a version with the fix” is not a valid answer.)
On-topic: “When I do X, Y happens. This is obviously a bug [e.g. because it's a crash], but I don't have enough information to make a bug report/avoid running into it. How can I find out …?” (Where answers might be thing like “look at /this/log/file” or “activate this trace mode”.)
On-topic, but do check official channels first: “What's the impact of bug B on a system where …?”
On-topic, but do check official channels first: “How does this security exploit work?” (While Stack Exchange isn't really the place for this, we've had a few great answers.)
I do not see why they would not.
First, it is hard to be sure you are facing a bug, reported or not, or another glitch involving something else (hardware, firmware, etc.). Not to mention that if it becomes clear that you are facing a bug, the community can advice and help you, to actually report the bug if it is not known, or to know that you are facing a reported one.
Second, when facing a reported bug, there are not always a solution being proposed by your distribution or, on the other side, too many "not-so-serious"/alleged solutions which could, in the worst case scenario, break your system. You can see the latter even in simple answers to simple questions on this website.
Finally, as far as I understand and I am concerned, this community is here to help users and promotes educational answers, which is, coincidentally, usually what happens where there are (serious) bugs reported to CVE website for example.
Long story short, asking such questions seems totally aligned with U&L StackExchange policy.
I think I agree with Gilles, but here is my reaction to the specific example:
Since some resent upgrades of my Debian testing/bullseye distribution, my user gets logged out while in sleep-mode (lid closed) [... name and version of desktop used, etc ...] Does anyone know how to fix this or which package is responsible for this behavior?
The version information is pretty good, thanks. You didn't give an exact package version apart from the kernel, but you're not sure which package triggered the problem anyway.
I read the question and left a comment, effectively suggesting to add certain additional information.
I think the described symptoms match a crash of gnome-shell (from sad experience). IMO there is a deficiency in this version of the question, in that it does not even show which program crashed, or that you have looked for crash information but found nothing. The problem is there could potentially be several different crashes with the same symptom during this development cycle.
Strictly speaking, I think this shows a flaw in the phrasing in this version of the question. You would legitimately like to know which package is responsible for the problem. I think the real question is how you can try to narrow down the problem, to find out more about the cause, and which package is responsible.
I think that's a useful way to understand StackExchange. I don't think it means your question is wrong. I think we should aim to engage with questions to try to reach a conclusion, not to nitpick them to death. IMO the question already shows some effort/thoughtfulness, and we're not currently in danger of being overwhelmed by such questions.
I don't think you're wrong to include the possibility that someone else already has a more detailed report, with the same symptoms as yours. On the other hand, if they saw your post then I expect they would make a comment anyway, even if you don't explicitly ask them to :-).
my system is not working properly, how can I fix it...this did not feel right for me, therefore I started this discussion and got plenty of aspects to take into account on these regards. Especially about posting more detailed information in the question.