Per Yannis' suggestion, I decided to go through the list of closed questions, pick out some specific examples, and make a detailed case for why those questions should be welcomed on the site. The first thing I discovered is that I agree with most of the close decisions. We close a lot of questions, yes, but most of those really do need closing. The other thing I found when going through the list one by one is that most of the questions that stand out to me as being unnecessarily closed follow a "getting started" theme.
To generate a list of questions for discussion, I searched for closed:1 start and clicked on the "newest" tab (although that generates some false positives). I'd like to go through the first several questions as examples.
https://softwareengineering.stackexchange.com/q/190127/3965 This question is a little chatty, but the gist of the problem is he has heard that self-taught php programmers can pick up bad habits from some resources, and is seeking expert advice to avoid that happening. Open for 1.5 hours, 1 upvoted answer.
https://softwareengineering.stackexchange.com/q/190095/3965 This question was seeking a general approach to finding third-party libraries and frameworks, a skill that's very important to professional programmers. This question was possibly too broad, but I think a skilled answerer could have pulled it off had it been left open longer. It feels like a "teach a man to fish" type of question. Open 3.5 hours, 1 downvoted answer.
https://softwareengineering.stackexchange.com/q/189927/3965 This one could use some editing for English issues, but a question about how much java background is needed to learn a language based on the jvm, does not seem to be an unreasonable question to pose to programming experts. Open 3.5 hours, 1 answer.
https://softwareengineering.stackexchange.com/q/189824/3965 Web development has changed a lot since 1996. It is not unreasonable to seek the advice of someone with more up to date skills. Also this is a different question from someone who has never programmed before, so the duplicate doesn't really apply. Open almost a day, 1 upvoted answer.
https://softwareengineering.stackexchange.com/q/189650/3965 This question is a good illustration that even expert programmers are newbies in some domains. Possibly could have been worded better, like "what characteristics should I use to evaluate a GUI framework," but mostly a good question to pose to experts in a programming domain. Open 3.5 hours, 3 answers, 2 upvoted.
Common Opposing Arguments
Here are some common arguments in opposition to these sorts of questions. Some from Are "Getting started with..." questions constructive? and some I've seen in various comments on closed questions.
The questions don't show enough research.
This is a chicken and egg problem. How are you supposed to research something if you don't know where to start with your research? If you are a beginner to a topic, how are you supposed to evaluate which resources are the best? Getting started is a natural topic to ask a group of experienced professionals.
They will produce inevitable duplicates.
So? We have a process for closing duplicates that works quite well, and there's little to no evidence to show getting started resource questions are any more likely to generate duplicates than other sorts of questions. And how is closing a question as a duplicate any more work than closing it as off topic?
People will just list their favorites.
We have a process for closing bad answers, and besides that, the favorites of experts is precisely the information we're trying to get at here. If people don't explain why it's their favorite, their answer will get deleted like for any other topic. If I want a list of 6,000 php books, I can search Amazon. Narrowing it down to the 5 or 10 favorites of experts is a lot of value to add, for which our site is well-suited.
These kinds of questions will garner too many answers.
This is not a unique problem to getting started/resource questions, which is why we have a process in place to prevent that. If you actually look at the questions that have been closed, they are no more likely than other types of questions to garner a large number of answers, even ones that were open for several weeks. Even if there are multiple answers, the best few will get voted to the top.
The answers will become outdated.
Again, how is this different from any other type of question? We work in a rapidly changing field. When an outdated answer is found, people comment on it and it's either corrected or deleted at that time. Also, getting started topics change much less rapidly than cutting edge topics. The basics stay relevant for a long time.
The only way to do it right is to create one heavily-moderated "canonical" question.
While this approach might be most appropriate on StackOverflow, where questions are expected to be highly specific and objective, "good subjective" questions are our bread and butter here.
It's too broad if you can imagine an entire book answering your question.
That's all well and good unless your problem is needing help to find the most appropriate book for a subject. These people aren't asking to have a book copied and pasted into your answer, just to get pointed in the right direction.
I'm not interested in answering newbie questions. This site is supposed to be for professionals.
Even expert programmers are newbies in some domains. If you personally don't want to see these types of questions, you can put them in your filtered tags list.
These are by and large good questions garnering good answers. They are the kind of questions you'd go down the hall to ask an experienced programmer, which are the kind of questions people naturally assume are on topic here. Welcoming these questions would go a long way toward improving our image with new users, and making it a better reference for experienced programmers learning new domains.
fooit should be tagged as
foo, so people who are familiar and interested in
foowill find it, and people who are unfamiliar or uninterested will not. The expertise level of the question shouldn't matter at all.