Shane Madden said:
We still want to make it clear that if it’s for someone’s home network, it goes on Super User. And if it’s a weak question that can’t be understood or has no detail, I expect the close-hammer to fall just as fast as before.
I'm glad Stack Exchange is taking this position :-)
What I’m about to propose isn’t intended to lower Server Fault’s quality bar, or open the door to everything that belongs on Super User being on-topic here.
I’m asking for questions to be considered on their merits, taking away the close criteria of “infer whether this person has the right job title” because that can’t be what we’re focusing on when we decide if a question fits.
Regarding "questions to be considered on their merits"... I agree, and a few weeks ago there was a strangely similar discussion about a guy who insisted that Network Engineering should help him build an ethernet cable for his home office. Aside from the coincidental timing of the drama, I wanted to share a few thoughts... perhaps we agree, but I'm going somewhere with the discussion.
SO has had a long-standing policy about judging questions on their merits, instead of the job description of the person asking. I agree with this policy, however, let's consider some of the differences between common SO topics and SF topics:
- SO: HTML and JavaScript
- SO: Compiled languages: C, C++, C#, Java, go
- SO: Scripted languages: Perl, Ruby, Python, PHP, shell
- SF: Unix / Linux system administration
- SF: Windows administration
- SF: Database administration
- SF: Network administration
I see a few notable differences between SO and SF questions:
- On SO, it's quite possible to replicate the OP's problem without hours of labor; particularly since there is an emphasis on creating a minimal, complete, valid example. People might not be terribly good at doing it, but it's at least feasible in many cases.
- On SF, it's quite challenging to expect people to build the same minimal example, because many questions are specific to the OP's work environment. For instance,
- I can clone someone's git branch and experiment with their code if I need to, but how exactly does one clone their linux server, SAN traffic, hadoop cluster, or network congestion?
- System administration also has a higher barrier to entry than programming. Even if I was inclined to spend hours building a virtual or physical mock up of an average SF problem, there are non-trivial licensing issues involved with replicating many environments (i.e. Windows, Solaris, HPUX, Juniper, Cisco...). By way of contrast, a lot of software can be written with free / open-source tools available to the masses (gcc, Eclipse, git, scripting languages, etc...).
So, what is my point?
The higher barrier to entry, and complex systems make it all the more important to get good documentation from people asking on SF; however, getting them to figure out how to document something is a chicken and egg problem.
We all say the same thing... the questions largely stink. On another site, I attempted to help people ask good networking questions, but even that (largish) document has not shown itself adequate yet. I'm not sure a self-scored checklist is the right answer; they need targeted feedback from the community.
Rhetorical question: How do you help a clueless person even know the right things to document? Speaking from very limited time moderating another site, it is pulling teeth to get people to put IP addresses and interface names on diagrams. If they simply knew how to document their problem adequately, I argue that at least 30% of them could solve the problem themselves. Yet, after trying for the last year to get good question documentation on a small beta site, I'm concluding that many people simply are not willing to submit to pleading in comments for even the simplest documentation, such as posting their configuration and an adequate topology diagram. NOTE: I have a feature request below that might improve the question feedback process.
My SF Feature Request:
I have a theory, which I hope Stack Exchange could help prove:
My theory: If we give people very specific feedback on what is missing from their question, as well as a complete example of what we expect to see then we stand a chance of getting better questions.
Feature Request: Give every SF question a scorecard, which indicates what is lacking from the question, and a good example of what it might look like. Every person who views the question can vote for whether the person needs to add information to the question.
The score card should look something like this to the OP:
- 54 people graded this question:
- 30% of reviewers are tired of seeing trivial questions from you (yes, I understand this bullet is controversial)
- 80% of reviewers are not happy with the current state of the question; 10% of reviewers think the question is adequate. 2% of reviewers think you did a good job asking the question.
- Requests
- 90% of reviewers think this question needs a good network diagram (include a hyperlink to what we think a good network diagram looks like, including subnets / interface names).
- 75% of reviewers think you need to add the version of operating system you're asking about (include a hyperlink to how you document the operating system for common operating systems)
The score card should be associated with each revision of the question. After a question is edited, the OP should be asked whether they included what was asked for. If they did, then the score for that element should reset. If they did not, then the score should carry forward. If people consistently lie just to reset the score card, they potentially could be suspended, or loose reputation.
In order to build a decent score card, we need to designate score card tags, such as windows, unix, network, http, etc... The tags would determine which score card is used for the question.
Finally, the score card must render well on mobile devices; most of the time I'm on stack exchange, I'm on my phone.
I realize that this suggestion is really a whole separate discussion itself, and I've hardly done a good job explaining the requirements. The point was to not just to gripe about how much questions suck, but hopefully offer a practical suggestion for improving status quo.
