Should 'feature request' on AU be noted off-topic like bug in the FAQ?

Question

Example. This question could be considered a skype feature request as opposed to a question about making a pseudo-device that is essentially jack for video.

Answer 1

I generally include those as:

"Not a real question".

Mainly because the only answer that we could give is the following:

If someone builds it, then yes.

With that being said, if people want to have it added to the FAQ, we can do that.

Answer 2

I think you should be cautious over marking some "feature requests" as a off topic question mainly because some of those can be actually answered and via some kind of magic, there can be something we can do. That is what Linux is stronger at.

Is there a way of... questions should not be automatically labeled off-topic. You just need to use common sense on those and mostly realize that you, as a person, don't know everything about how a solution can work.

I mean, if the question is "Can I have unicorns make me food every time I'm hungry because I am too lazy to get my ass out of my chair, and feed me via the terminal?" common sense will tell you, "No, no you can't, cause even tough Unicorns exist they don't know how to cook!" and that makes it a lame question. Mark is as a non question and move on.

If its about applying real time effects to a Skype feed and have some fun about it with my friends, probably there will be some way of doing it. If its about removing the background change in Unity greater (lightdm) per user base, there will be an answer for that, even if you need to hack a bit.

Again: Use common sense. If you think its impossible or that the question is a half rant about some feature that does not exist, vote on it, mark it as a non question or a off topic feature request and move on. Don't fuzz about it.

Answer 3

Speaking generally, I think:

Questions about features and capabilities are usually on-topic. True feature requests, or questions where the intent is not clear enough for a good answer to be posted, are off-topic (as we're not doing anyone any favors by leading them to think a feature will be implemented after being requested in a post here).

• If the post is a feature request, then it should be closed. Unless the feature really does exist, or fundamentally cannot exist. Then it should be answered with an explanation.

  If it's closed, preferably a comment should be posted explaining how it can be requested. Usually this would contain a link to Brainstorm, and sometimes also to Launchpad as feature requests can be filed as bugs. (They should not be filed as blueprints, though, unless the reqester can provide extensive technical detail and direction.)

• If the post might or might not be a feature request, and it's unclear what it's asking, it should be closed--perhaps temporarily--as not a real question, at least unless clarification from the OP is not immediately forthcoming. This includes posts that ask why some absent feature is absent, if it seems like the intent is probably to request the feature.

• If the post is not a feature request but is asking what is possible and how (for example, if it is asking if a particular feature is present or if a a particular task can be performed), then it's perfectly good and, unless something else is wrong with it, should not be closed.

  That includes the example in this meta question.

• If the post is asking about a design decision--why some feature is present or absent or why it works as it does--then this must be evaluated on a case-by-case basis. Often, such questions can be answered objectively. For example, when software is packaged for one Ubuntu release but not the next release, there's almost always an objective, clear explanation.

  A significant minority of the time, questions about design decisions are unanswerable unless someone from a very small group of developers (sometimes a group of one) were to show up and answer. Unless that person is active here, those questions can be closed.