<p>I don't see any real disagreements here.  The key is in the last line: if your interest in any question were to change radically upon replacing <code>R</code> by <code>BMDP</code> or <code>Systat</code> or whatever, then that is likely because the question is not asking anything about data analysis or statistics: it is asking about how to say the magic words to make the software behave.  That's what SO is for.</p>

<p><em>Of course</em> that does not rule out fielding software-related questions here on CV.  As Peter Flom points out in a comment, software is a necessary medium for doing data analysis.  (I have argued elsewhere that it's not a good medium for conveying ideas about data analysis, though, because there is no software platform that a majority of people doing data analysis are familiar with.)  We have always recognized here that many ostensibly software-related questions are, when closely examined, really questions about analyzing data, even though they manifest themselves as software-related problems.  We want to answer <em>the deeper question</em> about how to analyze the data rather than the immediate, shallow question about what to change in the code.  This, to me, is one of the keys to writing great questions and providing great answers: a great question provides enough information to identify the root cause of an issue and an awesome answer provides a revelation about that cause, increasing our understanding <em>regardless of what software platform we may choose to use ourselves.</em></p>

<p>I don't think anyone anywhere here has claimed that "using <code>R</code> is an act of programming." That's why programming is specifically mentioned in our FAQ.  When you are in fact using <code>R</code> <em>only</em> for programming, you are employing it in its capacity to do a job that C++ or Python or VBA or whatever could do, and you should prefer to address your question to a community of programming experts.  That ain't us: that's SO.  When you are using <code>R</code> to carry out statistical analysis or data visualization, your questions about that are squarely on topic here and always have been.</p>

<p>Recently we have been migrating an average of 2 questions per day (out of 50 per day total) to SO.  They are not all <code>R</code>-related: in the list I see a JMP question, a Stata question, and a Java question in the first ten.  What are the <code>R</code>-related questions about?</p>

<ul>
<li><p><a href="https://stats.stackexchange.com/questions/70105">How to compute a transition matrix from time series data.</a>  I disagree with this migration: this question invites answers that explain how to estimate Markov transition matrices and then <em>illustrate</em> the procedure with <code>R</code>.</p></li>
<li><p><a href="https://stats.stackexchange.com/questions/70051">How to reproduce a paper's results</a>.  Although it <em>could</em> be handled in a way that is informative, there seems little prospect that such an approach would appeal to the OP: he just wants the <code>R</code> equivalents of Stata commands.</p></li>
<li><p><a href="https://stats.stackexchange.com/questions/70063">This question concerns a package installation problem</a>.  That should be of no interest on this site: send it to those who love to diagnose such software problems.</p></li>
<li><p><a href="https://stats.stackexchange.com/questions/70041">Clustering time series by correlation</a>. This vague question really needed guidance from our community and IMHO is squarely on topic here.  I disagree with its migration.  However, the OP did get a useful answer on SO and her comments there suggest that maybe our community was right in its decision: the discussion is now focusing on details of <code>R</code> syntax and not the deeper issue of why this form of analysis is being attempted or how best to do it.  But maybe that's a self-fulfilling result: when a question stays here we discuss the data analysis implications and when it resides on SO, that community naturally addresses syntax, performance, and other computing issues.</p></li>
</ul>

<p>I could go on analyzing the migrations, but already some generalities seem to be emerging:</p>

<ul>
<li><p>If we adopt <strong>the approach of addressing every software-specific question as being</strong> (potentially) <strong>a question about data analysis</strong>, in almost all cases we will be right and the question need not be migrated (although it might need considerable improvement to deflect its original focus from <code>R</code> to the <em>application</em> of <code>R</code>).</p></li>
<li><p>If we <strong>pause to write a comment</strong> asking the OP about the nature of their question, we can be confident that we are directing them towards the community best suited to help them.</p></li>
<li><p><strong>We need to be a little slower to close questions.</strong>  When I review the statistics, I find that many of our community members who are voting to close are spending remarkably little time to make their decisions and some of them are voting far too often for closure.</p></li>
</ul>

<p>In brief, when you are in doubt about a question, <strong>don't migrate it, <em>improve</em> it!</strong></p>
