7
$\begingroup$

I have answered many questions here on engineering stack exchange, but I find it impossible for myself to ask an engineering question. Any question that I can frame to meet the rules, I could more quickly answer with 5 minutes of internet research. The things that I dont know about engineering and can not find on the internet require discussion or industry specific (sourcing) knowledge that other people have.

If you prohibit all questions that could infer discussion, all you end up with is a bunch of people that know nothing about engineering either asking for homework help or miss worded questions that require discussion/sourcing anyway.

I realize this is a policy of stackexchange in general, but I think it applies to computer programming a bit easier because there is less real world discussion to be had (sourcing and to some extent discussion can be reduced). Engineering, even academically, without substance or reflection on best practices is not very helpful.

I don't understand why legitimate questions like this one that is "sourcing" for sake of an example/clarity is put on hold. And questions like this one that is directly asking for a product source is fine.

I think the desire to build a good community and a solid question content base is getting lost in the necessity to follow old rules.

| |
$\endgroup$
  • 1
    $\begingroup$ Very much related: meta.engineering.stackexchange.com/questions/10/… $\endgroup$ – user16 Dec 14 '15 at 1:06
  • 1
    $\begingroup$ Also have a look at revision 1 and 2 of this question: engineering.stackexchange.com/posts/6518/revisions. The first revision is very clearly a "finding things" question, but the second revision is the result of an Atwood Transformation. $\endgroup$ – user16 Dec 14 '15 at 1:08
  • $\begingroup$ Also, there are cases where someone cross-domain might not know where to look in a giant pile of materials. See for instance my question re: zero clearance to combustibles ratings $\endgroup$ – ThreePhaseEel Dec 14 '15 at 3:03
  • 1
    $\begingroup$ @GlenH7 I did not catch the "Atwood" reference, but the link was helpful. So its not about what you ask, its about the semantics of how you ask it. Not being an english or comm major; the meaning I understood and answer I would have given, would have been the same with both versions. I guess my mind encodes both the same way. I suppose this is not true for everyone, but that would explain why I have a hard time distinguishing. Is there a way we could formalize this a bit better for people like myself? Even a table of correct vs incorrect ways to ask a question would be helpful. Thanks $\endgroup$ – ericnutsch Dec 14 '15 at 5:03
  • 1
    $\begingroup$ Jeff Atwood, Stack Overflow co-founder, suggested a particular approach to rewriting "shopping" questions; that's what Glen is referring to above. I added a reference link to his comment if anyone wants more detail. $\endgroup$ – Air Dec 14 '15 at 16:07
7
$\begingroup$

I find it impossible for myself to ask an engineering question. Any question that I can frame to meet the rules, I could more quickly answer with 5 minutes of internet research.

Yep - I find myself in that position on Stack Overflow a lot of the time.

The primary goal of any SE site is to improve upon the existing aggregated Internet resource for questions in a certain problem domain. There are gaps in what engineering problems are easily solved via Google. There are questions that have only subpar answers on other sites, or decent but incomplete answers, where we can create something better.

It can be hard to ask a good question on SE when you:

  • Are a pretty skilled and dedicated researcher; you tend to either find what you need just as quickly on your own, or else never get to the point of feeling like you're "done" researching.
  • Have access to a lot of expertise in the form of coworkers, instructors, mentors, etc. Why take the time to do a write-up and wait for volunteers to post answers that you don't know if you can even trust, when Bob has 45 years in the industry and his cube is two aisles down?
  • Work on projects that are well-documented, that have an established procedure, that have training materials, that are running smoothly. When you have to do something you haven't done before and your attempts fail outright, but someone has probably done it before, Stack Exchange wants to close the gap between you and that someone. If you don't have that sort of problem - let's be honest, that's a good thing.

That's not even a remotely exhaustive list. I'm trying to illustrate the particular niche that this site wants to fit into and that it's designed around, by examples of situations that don't necessarily call for the particular solution we're offering. We're not a Swiss Army knife, we don't do it all.

If you prohibit all questions that could infer discussion, all you end up with is a bunch of people that know nothing about engineering either asking for homework help or miss worded questions that require discussion/sourcing anyway.

We don't prohibit questions based on whether answers could infer discussion. There is actually a post notice that moderators can place on answers that don't go into enough detail, which says that good answers explain and provide context. That kind of answer often leads to some amount of discussion in comments, which is fine. Sometimes the comment constitutes a valuable addition; sometimes it adds to the site indirectly, by prompting a user to improve their answer.

What we do not want is content that is dominated by conversation. We need to be able to go through after the fact and separate the wheat from the chaff. When I say "we," I don't just mean moderators deleting comments—I also mean regular users voting and flagging.

There are lots of sites on the internet where you can wade through pages and pages of threaded conversation to get a rich, nuanced view of a complex problem. Though if we're being honest, 90% of the time what you're actually getting is a rich, nuanced view of how to have petty arguments, go off on tangents, not support arguments with evidence and get people to read something for twenty minutes that ends up not solving their problem at all.

Needless to say, we don't aspire to that.

I don't understand why legitimate questions like this one that is "sourcing" for sake of an example/clarity is put on hold. And questions like this one that is directly asking for a product source is fine.

In the case of individual questions that you think should or should not be allowed, this is a community-moderated site; even if a mod interprets a question as off-limits based on an existing policy, you can disagree and you can cast a vote to reopen the question. If that goes nowhere, you can dedicate a Meta conversation to the specific question; yes, that is allowed, once you've exhausted other avenues.

As it happens, both of those questions are now open. Personally, I think both are poor questions and I've voted accordingly. But the community decided the first one needed improvement, and then decided that the improvements it got were good enough. The more of us take part in those decisions, the better.

| |
$\endgroup$
  • $\begingroup$ Thanks for framing out the process and environment a bit better. I think most people already understand the system as they are vets from other SE communities, but for a noob like myself it helps out a lot. Thanks. $\endgroup$ – ericnutsch Dec 16 '15 at 3:48
  • $\begingroup$ Even veterans often have trouble seeing the forest for the trees if they haven't followed breadcrumbs from their Meta site to MSO/MSE, to blog posts by Jeff, Joel and staff, to podcasts, etc. If you follow them long enough, you eventually find something like the five minutes in the middle of an hour-long Google Tech Talk that explain why so many things are forbidden on the network. Moderators can help by investing that time and synthesizing what they find so you don't have to. :) $\endgroup$ – Air Dec 16 '15 at 16:31
4
$\begingroup$

You bring up some good points. Engineering more than some of the other topics for which there are SE sites requires discussion, and when you get to a certain level of complexity, there are often multiple correct answers. However, the format of SE sites does not foster discussion well. You don't have threads, you have individual answers to a question and comments that will never function properly as a discussion section because they're not intended to be. Unfortunately, for this reason, I think there are certain questions and topics that we'll never be able to adequately handle here. There are specific site mechanics at play preventing us from having open-ended discussions and there's really no way around that.

However, you should note that the close reason on your question is too broad, not off-topic. Sourcing questions are in the off-topic list, so unless the close voters just selected the wrong reason, the sourcing aspect is only part of why they voted to close. As theNamesCross noted, your question as it is originally stated is very open-ended and tells us little about the application. Your edits clarify things, and they move in the direction that I would recommend: asking how to achieve a specific task or make a specific decision.

Asking "How do I create a tamper-proof container?" is a better question than "What are some impenetrable materials?" The second will be a list that is either never complete, or in the case of something that might not be possible, full of things that come close but never fully meet your specifications. This also creates a better resource for people in the future, as they will get answers about how to go about doing something rather than a rote repetition of facts, especially when the "how" answer will often include those facts.

On a side note, the other question you link is still open because it asks a very specific question. It's not looking for recommendations on a material or a list of options. It asks what a specific product is made of, and also asks how it works. Now, if you compare the material aspects of that question to my criteria above, you might say "it doesn't fit any of that!" and you're right, and I would say that part of it is not a great question. But it's not off-topic, it's not overly broad, and it shouldn't be closed. It's not a great question, but that doesn't necessitate or even justify closure. I think yours is a better topic with more lasting potential, but is focused on the wrong parts of the issue.

| |
$\endgroup$
  • $\begingroup$ I will pay a little closer attention to the reason questions are being put on hold/closed ; thanks for catching that. I guess the correct approach would have been to reword his question to be "How do I create a tamper-proof container?"? I am willing to do this; im just not sure where that line is drawn. I dont want to be the guy that rewords a question into something the author didnt intend. $\endgroup$ – ericnutsch Dec 16 '15 at 3:34
  • $\begingroup$ @ericnutsch And that's a classic SE trap. But also, I totally didn't realize you weren't the one who asked the original question. So disregard that framing in my answer. $\endgroup$ – Trevor Archibald Dec 16 '15 at 3:36
  • $\begingroup$ @ericnutsch It's true that the author's intent is important but mainly in the sense that we want to make sure the end result is still a solution to their problem. As far as aggressive edits are concerned, I like Wikipedia's policy. We can always revert if necessary. $\endgroup$ – Air Dec 16 '15 at 17:29
3
$\begingroup$

In casting a 'close vote' on Are there any materials that can not be drilled or sawed? [Rev.1], I owe my $0.02.

Despite your good answer, in my opinion, "Be aware that anyone with enough time and money can defeat tamper evident materials/designs." and similar statements exemplify the open-ended nature of the question. Simply put, entire books are devoted to material selection, machining, and tamper-proof assemblies.
In my judgment, any answer given is ultimately incomplete (or "it depends...") without mention of the configuration, application, acceptable level of damage, etc. That said, I'm happy to remove my close vote (and suggest changing the title to better reflect the modified question).


Finding common ground, I agree that engineering topics require more discussion than most other StackExchanges. Often there are multiple ways to approach problems, all with advantages and disadvantages. Experience is not learned from books- discussion sheds light on practical considerations and overlooked aspects of design (ie. tolerances, material selection, safety, codes, resonance, to name a few). Without question, we all benefit from the collected wisdom and experience of Engineering.SE peers.

Oppositely, I argue that open-ended or unclear questions should be closed because they invite equally open-ended or unclear answers/discussions that potentially misinform.

  • Answers are forced into making unfounded assumptions- it is not our place to judge what the OP meant, or what "reasonable values" to assume. Without precision, important subtleties and specific context are lost. A little knowledge is a dangerous thing.
  • Answers are forced to omit important information for brevity, where a complete answer would require an entire chapter/book(s). You don't know what you don't know.

I embrace your desire for discussion but cant propose any constructive changes to the status quo. I fear that intended discussion questions will become too broad to be useful (ex. "What is the best material?").

| |
$\endgroup$
  • $\begingroup$ I guess open ended questions are a part of everyday life as an engineer; so havent been distinguishing. I think with everyones answers I should be up to speed on the SE format now. Thanks. $\endgroup$ – ericnutsch Dec 16 '15 at 3:46
  • $\begingroup$ @ericnutsch Apologies if my answer appears critical- I think its a good question, but I felt compelled to explain my close vote. In practice, open ended questions are valuable and common. Hopefully we can propose ways to make them fit within Engineering.SE in the future. $\endgroup$ – OnStrike Dec 17 '15 at 7:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .