22
$\begingroup$

TL;DR: Recently, it seems to me like we have been a little trigger-happy about closing questions as "only about software/programming". I ask that we please ease off a bit.

Our help page on on-topic-ness says (emphasis in the original):

if it [the question] needs statistical expertise to understand or answer, ask it here

The closure notice I am concerned about here says:

This question appears to be off-topic because EITHER ... OR it focuses on programming, debugging, or performing routine operations within a statistical computing platform.

Now, of course there is a continuum and room for reasonable disagreement as to where "needs statistical expertise" ends and "programming, debugging, or performing routine operations" begins. I will happily VTC questions on R that ask about how to use the *apply() functions, or how to create a particular plot in ggplot. My personal litmus test usually is whether J. Random R Programmer would be expected to be able to answer, potentially on StackOverflow. (I am not concerned with "unclear" questions here.) As in: are help pages and R tutorials enough to answer, or do we actually need to know some statistics?

However, here are just two recent examples of questions that were (almost) closed, although I would definitely argue that the "needs statistical expertise" criterion is met - even if this expertise need not be very deep:

  • Why are my fitted values returning greater than 1 in GLM? OP ran a logistic regression with glm() without specifying family=binomial. You need to understand the difference between OLS and logistic regression to answer here. No, this is not statistical rocket science, but it's something a run-of-the-mill programmer does not know.

  • Can I use bottom up, middle out, or top down approaches with fabletools:reconcile? OP struggles with what I would consider a beta release (the 3rd edition of an online textbook, which is missing a key chapter that can be found in the 2nd edition, and a very rudimentarily documented R function). To answer, you need to have an understanding of hierarchical forecast reconciliation. I referenced JASA, the International Journal of Forecasting and Computational Statistics & Data Analysis in my answer, and necessarily so.

Sometimes it feels to me like some of us see a question that asks about R, perhaps even in the title... and jump to conclusions.

I ask that we please be just a tiny little bit more relaxed about leaving questions open where there might be some statistical aspect, even if it is in the context of software.

Alternatively, we could be more stringent than I would prefer. Fair enough. But then we should communicate this explicitly in our on-topic help page, and hopefully have a discussion here beforehand.

And of course we have discussed similar topics before, which in fact informed our current closure notice as cited above, and also our on-topic page (?).

$\endgroup$
18
  • 1
    $\begingroup$ Agree with you on the first example, though with the second one I'd probably consider voting to close. Agree that it's subjective. $\endgroup$
    – Tim Mod
    Commented Oct 6, 2020 at 20:32
  • 1
    $\begingroup$ Re the first one: I closed that one immediately upon seeing the problem was failure to invoke the function correctly. I don't see this as being a particularly close call, because anyone with the minimum amount of knowledge needed even to use this function would understand what that argument means. Re the second one: I did not VTC precisely because I try to moderate cautiously and, despite having no familiarity with this software, suspected an answer might require some statistical expertise. Thus, I maintain that the right decision was made in both cases and nobody "jumped to conclusions." $\endgroup$
    – whuber Mod
    Commented Oct 6, 2020 at 22:18
  • 5
    $\begingroup$ Having written that, I should add that I have had similar feelings about the apparent haste to close some questions as software-only. Perhaps we can come up with better examples of the edge cases and use that as the springboard for characterizing them and providing constructive guidance to the community. $\endgroup$
    – whuber Mod
    Commented Oct 6, 2020 at 22:19
  • 3
    $\begingroup$ I don't disagree with the stance here but I boggle a little at the thought that there are R programmers who don't know statistics, or more precisely at the thought that there might not be enough statistical expertise on SO to apply also to questions mixing statistics and programming. (I only use R occasionally and am no expert on the community.) Another criterion I sometimes apply is How far could this possibly interest someone who doesn't know or care about the language concerned? $\endgroup$
    – Nick Cox
    Commented Oct 6, 2020 at 22:53
  • 3
    $\begingroup$ Let's agree that -- although the examples here concern R and that seems by far the most common single language -- the principles cover all kinds of software. $\endgroup$
    – Nick Cox
    Commented Oct 6, 2020 at 22:55
  • 5
    $\begingroup$ @NickCox: this phenomenon might be more prevalent among Python users. There are lots of people who learn Python for "general" use and later start doing Machine Learning using sklearn and similar. These people typically know very little statistics, and they may indeed not know about the Python equivalent of the family parameter. If you learn R, you typically do it for statistics from the very start. As such, my examples may have been ill-chosen. $\endgroup$
    – Stephan Kolassa
    Commented Oct 6, 2020 at 22:56
  • 12
    $\begingroup$ A nuance here is that some users come to stats.SE after becoming familiar with the standards of SO.SE, which typically requires a MRE for questions. I surmise that these users sometimes include large blocks of code which are not really essential to their question, but attempting to adhere to the SO.SE standards for questions. Appearing as such in the stats.SE context, the questions appear to solely concern programming or debugging but are in fact statistical at their core. It requires a careful reading of the question to decide which is which, and sometimes I've only realized I was wrong after $\endgroup$
    – Sycorax Mod
    Commented Oct 6, 2020 at 23:13
  • 5
    $\begingroup$ Indeed. I boggle even more when I see "I am learning Python and new to machine learning and I want to program X", where X is some highly challenging goal like detecting fraud or predicting stock prices. I am sure there is a joke in there about snake oil somehow. $\endgroup$
    – Nick Cox
    Commented Oct 6, 2020 at 23:29
  • 4
    $\begingroup$ @NickCox You joke, but there's a lot of entry-level work in the world of fraud prevention, in the sense that some high-level executive will tell their IT staff or database team to "figure out some patterns using big data" and suddenly folks with deep knowledge of their computer systems have to become experts in statistics. I've seen this pattern at a number of organizations. It's alarming in retrospect, but also how I got started in this field. $\endgroup$
    – Sycorax Mod
    Commented Oct 7, 2020 at 2:49
  • 4
    $\begingroup$ @NickCox: what Sycorax says. I have seen this exact dynamic at play in time series forecasting. And the saddest thing about it is that if there is any snake oil involved, then it's people selling it to themselves. (Or top management insisting on it.) And as a matter of fact, we have a Meta question on pretty much precisely this. $\endgroup$
    – Stephan Kolassa
    Commented Oct 7, 2020 at 6:37
  • 2
    $\begingroup$ No one wants to make a wrong decision, but making a prompt decision can be in the OP's best interests as well as the community's, especially whenever a question is in good shape for SO and should just be migrated. @whuber's "apparent haste to close" might indeed mean a kind of reflex reaction "but this is just another programming question". I've noticed that I vote more to close software-linked questions than some others, but my vote to be decisive depends on others agreeing. $\endgroup$
    – Nick Cox
    Commented Oct 7, 2020 at 9:06
  • 2
    $\begingroup$ I agree that there is much haste on closing software related questions. domain expertise is often requiered to answer programming question, and it is much more so in the case of statistical software which is so far from low level programming. of course not every question requires statistical expertise, but many ones that get closed, in my opinion, do. $\endgroup$
    – carlo
    Commented Oct 8, 2020 at 11:38
  • 4
    $\begingroup$ I have a similar impression, @Carlo, but I would suggest refining your focus to consider only the software-related questions that would not otherwise be closed because of other defects. The majority of questions that we close ostensibly because they are software-focused would nevertheless still be closed because they are not well-formulated questions. The ones that are good questions get migrated to Stack Overflow, but that happens in only a tiny fraction of cases (on average, that happens once per day but we close over 100 questions per day). $\endgroup$
    – whuber Mod
    Commented Oct 8, 2020 at 20:28
  • 1
    $\begingroup$ On Meta upvoting the question often means "this is a good question" and not necessarily that OP's stance is agreed on exactly We have criteria to follow on what is acceptable here on CV -- but if experienced people disagree on where posts fall the problem may be (a) the criteria are just not precise enough (b) the criteria are clear but there is still a judgement problem -- academics use criteria in grading but that doesn't stop them disagreeing on whether work is good, or excellent, or whatever, and the same problem is universal (c) the fault lies in the individuals who disagree with you. $\endgroup$
    – Nick Cox
    Commented Oct 14, 2020 at 12:19
  • 1
    $\begingroup$ (c) is an allusion to an assertion made elsewhere. $\endgroup$
    – Nick Cox
    Commented Oct 14, 2020 at 12:20

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .