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.
This extra step can be optional - if you don't mind rough treatment or are confident of approval you can skip it...
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.
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)
==
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".
That said - I'm very curious if there are aspects of this that I'm missing that make this perspective insufficient.
However, these "gatekeepers" can be just as unhelpful.
I have been studying this behavior for some time - and it's very interesting. I have found that C++ communities to contain members that talk down to new members, yet in Assembly language communities (which is arguably a harder more advanced language than C++) I have seen members offer extremely helpful advice and even sample code.
Sometimes though people can be too friendly - in some communities people post something they are working on (which is basically a copy/paste from the sample code provided by the language/library) and the other members are like "THAT IS AWESOME".
I'm not saying library/language/framework developers have to remote into people's computers and hold their hands - but at least try to show some professionalism and respect. Instead of replying with "this has been asked a 1000 times - please use the search" and close/lock the thread, reply with "Have you seen these other threads? They may contain what you are looking for - otherwise let me know". The later will go a lot further in encouraging new members to join and current members to stay. To me, in my opinion, the first indicates a lack of knowledge and/or maturity on your part.
From what I hear, the subversion guys are always polite and have used this to battle off trolls. Be immature as the trolls and you are just feeding the trolls...and the sign is clearly posted "Don't feed the trolls".
The issue is that it really appears that it is a clash in personalities. When someone says they love R's community and then emphasis that it is a terrible language they lost me. In Open Source there are many examples of "mean" gate keepers. We see splits in the communities with examples all over i.e. ffmpeg vs libav.
This isn't the way to go about change by belittling the language and then say ALL of mail list when he has a personal issue with one person. This is not going to be healthy nor helpful unless there is documentation on conflict resolution that already took place.
Just my humble opinion.
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: https://github.com/wch/r-source/commit/4f13e5325dfbcb9fc8f55...
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."
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.
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"): https://en.wikipedia.org/wiki/Online_disinhibition_effect
This can be easily countered with setting user quota (per day of week or whatever) on emails to the list. Not that this is a cure for all - but I believe this can improve the democracy of mailing lists. I hope some mailing list management software will add this as an option some day.
http://blog.revolutionanalytics.com/2014/09/new-members-for-...
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.
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).
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.
Am I wrong?
I could see alternate curated repositories from CRAN, but to switch from CRAN I'd still want some kind of curation.
I suspect he may be about to find out.
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.
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.
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.
It seems childishly wasteful to turn away potential contributors because you simply feel you have the right to be an asshole to people. Personally, if you want to treat me harshly for my work, I expect some good money.
* Paraphrased reaction to software a classmate sent in after completing her thesis
In contrast, there was another project where my student and I noticed a bug in a piece of software and patched it. It was quickly accepted and we moved on. I would be happy to contribute to that project again.
It's all about barriers to entry. If a project wants outside contributors, those barriers need to be low. Of course, the project creators/maintainers are also doing this in their free time, so have the right to do what they want, but they should expect less community contributions if they make those barriers high...
Citation?
A raw assertion is not helpful.
Just let it go...
And in open source, if you spot a problem: fix it by contributing.
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.
Instead of whining he should take part of the load. Especially if he ares about the community.
Regarding the remaining line, you appear to be suggesting that anyone who spends their spare time helping people, or volunteers in some way, is entitled to be rude and unhelpful. Is that really your position?
A small number of people are very busy. They can also be rude.
Being welcoming to people while avoiding the tarpit of HelpVampires is important and is not yet a solved problem.
Since many people on HN work on products that want some kind of community it's possibly a useful topic.
I kind of wish that MeatBall Wiki was easier to navigate and expanded their online personality stuff. It'd be a fantastic resource if they did.
"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.
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.
There are certainly vital roles for Developers who want to remain technically focused at the complete expense of human interaction, but (like it or not) it will limit the opportunities open to them.
I would suggest that acting as the public face of a gatekeeping process is the wrong role for anyone who doesn't like dealing with people and/or has trouble interacting with them politely or helpfully within the time available.
Perhaps the role would be better split between two people: a public-facing person and a purely technical gatekeeper. The gatekeeper then only has to deal with the public-facing person, who can provide potential contributors with help, assistance, and common human decency, as well as acting as a first level filter. That seems like a win-win for everyone.
Edit: Just spotted that avivo already suggested this. https://news.ycombinator.com/item?id=8922331
I originally asked if the author is an adult, but then I decided to revisit the article and saw the link to his CV (http://ironholds.org/cv.html). 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.'
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.
Based on the other available evidence (the linked article, his acting as an Equality & Diversity Officer and as a political campaigner for a party which - at that time - was pretty keen on people's rights) one could more easily conclude that he cares deeply about how people treat other people, and how people can work together to get better outcomes for everyone.
