Would one potential solution be to create a secondary optional gatekeeper?<p>The basic idea would be - don't submit directly. First submit to the community gatekeepers, they will look over your work, and if they think it will meet approval, they'll pass it on. Otherwise they can give helpful feedback. They can have strong standards about how contributors are treated.<p>This extra step can be optional - if you don't mind rough treatment or are confident of approval you can skip it...<p>The result: less work for existing gatekeeper(s) without changing their process, more friendly and helpful interactions for contributors, and no slowdown if you really know what you are doing.<p>Of course the cost is that people need to volunteer to be that secondary gatekeeper! (and have some tough skin when interfacing with the primary gatekeeper)<p>==<p>In an ideal world everyone would have the skills and interest to efficiently be pleasant to everyone else while vetting infinite code. But in this world of finite time and not everyone having every skill it can make sense to have some more "division of labor".<p>That said - I'm very curious if there are aspects of this that I'm missing that make this perspective insufficient.
This should really be titled: "Don't use the R mailing lists", initially I thought it was an essay against the use of mailing lists in general.
This is probably a hard post to evaluate from the outside: is he right, or just overly sensitive? Earlier I would have been skeptical, but I've recently started on a project in R, and based on my experience so far I think he's mostly right: there are some real problems with R development. But I'd put less emphasis on individual "bad apples", and more on a culture that is dealing poorly with the approach of "development in the open". I think this recent exchange on the list illustrates nicely: <a href="http://r.789695.n4.nabble.com/PATCH-Makefile-add-support-for-git-svn-clones-td4701971.html" rel="nofollow">http://r.789695.n4.nabble.com/PATCH-Makefile-add-support-for...</a><p>The R source repository is in Subversion. A new contributor offers a very small patch to allow source downloaded from a git mirror to compile correctly. The response (not from Ripley) is "I think we are unlikely to accept this change. Nobody in R Core uses git this way, so it would never be tested, and would likely soon fail." A reasonable position in some cases, but seems odd for a two line patch a Makefile that opens development to new contributors. Even stranger, it turns out that the patch is mostly working around a commit from several years ago (by Ripley) to explicitly prevent compilation from git: <a href="https://github.com/wch/r-source/commit/4f13e5325dfbcb9fc8f55fc6027af9ae9c7750a3" rel="nofollow">https://github.com/wch/r-source/commit/4f13e5325dfbcb9fc8f55...</a><p>Even stranger, this commit is commented "trap HK Leung misuse", where Han-Tak Leung is an earlier mailing list participant who had problems compiling as a result of using the "git-svn" compatibility layer. The thread discussing that earlier issue concluded (not Ripley): "The generic point is that you are given access to a working tool that is internal to the core R developers. We are not putting restrictions on what you do with that access, but if you want to play the game by other rules than we do, you need to take the consequences. If things don't work and you start complaining about them being "broken", steps may be taken to make it clearer who broke them."<p>Considering the source repository and ability to submit patches as "access to a working tool that is internal to the core R developers" strikes me as a short-sighted approach. Spiking your source to refuse to compile if not checked out directly from svn seems like a bad strategy. Explaining the purpose as to "trap misuse" by an individual might be pathological. It makes me pessimistic about R's future.
The same thing seems to happen in many mailing lists or newsgroups once they reach a certain size, as well as on discussion boards, stackoverflow, and other sites like wikipedia. One person called them 'RTFM jerks': <a href="http://www.linuxtoday.com/infrastructure/2006033100126OPCY" rel="nofollow">http://www.linuxtoday.com/infrastructure/2006033100126OPCY</a>
On the python lists, they were called NIMPY ("Not in my Python!"): <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=87182" rel="nofollow">http://www.artima.com/weblogs/viewpost.jsp?thread=87182</a><p>You combine a power structure (control over others in some respect) with pseudonymity and you'll accelerate this problem. Even without a power structure, people will try to dominate, bully others, by posting more frequently than anyone else in an effort to drown out other opinions or contributions. The anonymity disinhibits this behavior further (called the "greater internet fuckwad theory"): <a href="https://en.wikipedia.org/wiki/Online_disinhibition_effect" rel="nofollow">https://en.wikipedia.org/wiki/Online_disinhibition_effect</a>
Perhaps some of the disagreements in working style are due to shifts in the R community? Ripley has been an active member of the Bell Labs S, and later GNU R, communities for about 20-25 years, over which period the user/contributor composition has shifted considerably, which might produce different shared norms/expectations and different friction points. 20 years ago the community was much more exclusively comprised of computationally oriented PhD statisticians, among other differences.
The R Core Team has included a lot of new members to its team. A lot of those members are mentioned in this article as positive to the community.<p><a href="http://blog.revolutionanalytics.com/2014/09/new-members-for-r-core-and-r-foundation.html" rel="nofollow">http://blog.revolutionanalytics.com/2014/09/new-members-for-...</a><p>Community building is something new to R in my experience. I would give it a little more time. I would also like to reiterate one of the strongest tenets of free software is that it is only as big as what YOU put into it.
CRAN is core and has to be trusted, the alternative community pointed to by OA provides a way of publishing newer libraries and applications built on core.<p>Seems logical to me that the barrier to the former is higher than the barrier to the second (essentially no barrier, just put it out there and see if people like it and be prepared to respond to feedback).<p>Perhaps the 'tone' of that higher barrier to the core could be adjusted and mechanisms for submission made clearer, but I think that there needs to still be a standard.<p>Am I wrong?
Ultimately open source software is approved by many eyes, for which Github seems like a natural place. Many excellent packages are already only available via devtools::install_github(). CRAN is nice and easy (especially for people starting with R or with programming) but is not a necessity.
"<i>...I know of a lot of people who simply refuse to argue back, or address the problem of tone, or do anything in dealing with him, because they're afraid of blowback in the form of "good luck getting anything approved ever again". Whether this is a plausible outcome or not is unknown,...</i>"<p>I suspect he may be about to find out.
While this may not be the case in this situation, recently I've noticed that people are becoming extreme wimps..<p>People, especially younger generation can't stand being treated harshly. You can't criticize them, and every response must be nice, politically correct and helpful.<p>Sometimes you just have to let it go, or simply fight back. And when you do fight back, be prepared because it's unlikely that you will win every time.. Such is life. Grow a pair.<p>When I was younger it was normal for kids to fight in school. Nobody really cared if you got your ass kicked once in a while. And often times you kicked some ass. This helped people realize that not everyone in their life will be nice and helpful, and that sometimes you need to have a thick skin and ignore what people are saying. Now it seems kids, when they get laugh at or in some one offended, if they can't get help from the adult they just grab a gun or a knife and start killing people because they simply never had a chance to learn how to deal with competition.
This attitude is gross: open source contributors are not your bitches.<p>And in open source, if you spot a problem: fix it by contributing.<p>Shaming someone publicly (isn't it bullying?) that contributes a lot for «being unnice» on his spare time helping people is like shaming a construction worker for being sweaty.<p>Instead of whining he should take part of the load. Especially if he ares about the community.
This just made me think, if the maintainer is just part of a process - maybe compilers should be more polite, too.<p>"Syntax error at line 57" sounds very harsh. Why can't the compiler say "dear developer, it shames me to point it out but you might have slipped in a typo on line 57. Your continued effort in straightening it out would be much appreciated" I would be much more motivated to continue debugging.<p>What I am getting at, maybe the maintainer sees his role more technical than social. He considers his job to maintain the code base, not the user base. I actually think that's OK, and submitters shouldn't take a brief response personal.
In the time it took him to write that post, he could have found his unterminated string and resubmitted.<p>I originally asked if the author is an adult, but then I decided to revisit the article and saw the link to his CV (<a href="http://ironholds.org/cv.html" rel="nofollow">http://ironholds.org/cv.html</a>). I'll note that the picture he chose is himself as a small child and that he proudly notes, 'while at university I (amongst other things) occupied my time with acting as the Equality & Diversity officer for the Students' Union, and working as a political campaigner for the Liberal Democrats.'<p>This leads me to conclude that no, he's not an adult, self-reliant and self-actualised, but is instead still mentally a child, dependent on others for validation. I'm sure he's a very smart guy, but he has got to grow up.