But I will say this, I hope nobody is sent away with hard feelings for asking a "questionably" dumb question or making a "questionably" dumb statement
Look - that's not the issue.
It's often said that there are no dumb questions. I don't think that's true - there are. If you ask something that you could have figured out in 3 seconds yourself, that's wasting time and falls into that category. As I type this, I have a pink box with requirements what info to supply for a bug report on screen right above the box into which I am typing. To disregard that and assume that people can figure a bug from a vague description like 'FG sometimes crashes' would be an example.
Not the issue here.
The issue here is twofold: Equal effort, and politeness.
Let's start with the second. If I know something, I make a statement of fact. If I am not sure, I say 'I believe X is like this'. If I don't really know, I ask a question 'Could it be that X is like that?' This is to let the person I am talking to know the level of certainty in the information I give - if I state my assumptions as facts, you can imagine how they're quoted down the line as truths and how everyone gets royally confused. And if I stated something as fact which turned out to be wrong, I apologize for having spread wrong information (I feel actually ashamed if I do that, in case someone is wondering).
So, where does politeness come in? It's in assuming that people who have developed an aircraft (autopilot, subsystem,...) know a lot about it. Say I have a problem with the autopilot of the Y-55 plane. My default assumption is that the person who developed that can operate the autopilot or is in the process of working on it, because we usually don't commit broken stuff just for the sake of it, we commit what we can use ourselves. So it's unlikely that the AP is completely broken (it can happen if it depends on other systems which have changed though) - it's far more likely that there's an issue on my side - either specific for my computer, or something in the way I operate the thing. In fact, observing my own case history, at least 8 of 10 cases the problem did turn out to be on my side when I reported such things - about half and half specific configs and my mistakes in using a system. More often than we think, the problem sits right in front of the screen
How do I now report this AP problem? Here's some variants with the implied message:
* The AP of the Y-55 is broken
(What kind of a stupid person are you to need me to tell you that - shouldn't you have realized that yourself and now you need me to tell you?)
* The AP of the Y-55 doesn't work on my system
(There may be something specific in my config which makes this not work which you might not have considered)
* I can't seem to be able to operate the AP of the Y-55
(There may be something in my config or my way of handling it which doesn't agree with what you assumed)
* I can't seem to be able to operate the AP of the Y-55 - this is what I am doing, this is what I expect, this is what I get and I have consulted this reference
(I've exhausted all avenues of information to address this myself, and I still find a problem)
Which of these questions would you prefer to deal with? I like best to be asked politely.
Which brings me to the second point - equal effort. We have two parties which want to exchange information. A knows stuff, B has a question. What B wants is a comprehensive answer and discussion, in non-technical terms, with the ability to ask questions and ideally a ready-made patch which fixes the problem.
But A has a time limit - he can explain, or develop, or document, but not all of these, but A sees the need to provide answers. So what A wants is to keep the answer as least time consuming as possible, i.e. he wants to give a pointer 'Look up on covariant metric transformations' and then let B do the information gathering and structuring.
So, if we want a meaningful exchange, A has to make an effort in structuring the information he has such that it is comprehensible. B has to make an effort to structure the information he gets such that he comprehends it. And the efforts of A and B should be on average equal (modulo the fact that A may address questions of different users simultaneously). If you take 30 seconds to type a question because you didn't want to do a wiki search, you can feel entitled to a 30 second reply 'read wiki page XY' by this principle.
I go out of my way to help people who are actually interested in working on something or analyzing a bug such that it can be fixed, i.e. actually try to read some beforehand and look into the resources I point out, look into files I point out and try different settings, etc. I turn my back on questions which want a ready-made solution, have obviously not done even a cursory search of the forum or the wiki and signal no intention to put some effort into understanding/debugging - these are, from my experience, lost causes which take my time and accomplish nothing because I can't magically guess problems on other systems, and my time is better invested in helping people who put effort of their own in.
The issue here is not about asking stupid questions, the issue is about managing information flow. You may want to get someone's exclusive attention and help, but that ain't working if that person has other things to do, so you need to structure the exchange in such a way that it benefits both sides, not only yourself because that is working. Politeness and equal effort are keys to do that. As simple as that.