Don't use the mailing lists(blog.ironholds.org)
blog.ironholds.org
Don't use the mailing lists
http://blog.ironholds.org/dont-use-the-mailing-lists-a-love-letter-to-the-r-community/
16 comments
It could be a solution but that already kind of exists (with forums/IRC etc).
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".
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".
Not defending anyone just a 30,000 foot view.
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 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.
Down vote for giving an opinion great to see the defenders of Hacker News.
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: http://r.789695.n4.nabble.com/PATCH-Makefile-add-support-for...
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.
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.
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': http://www.linuxtoday.com/infrastructure/2006033100126OPCY
On the python lists, they were called NIMPY ("Not in my Python!"): http://www.artima.com/weblogs/viewpost.jsp?thread=87182
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
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
"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."
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.
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.
Some of the Wikipedia mailing lists did this a year or two ago, adding a limit of 30 posts per person per month. Not sure it's had any significant impact on the community, but it has somewhat reduced the volume of a few really, really prolific posters, which is a slight improvement to the S:N ratio. (There exist mailing lists where the most prolific posters are also good contributors, but imo this is not true of the Wikipedia lists, so the cap has mostly excluded posts I find noisy/redundant.)
Interesting! I would rather use a one per day limit instead of 30 per month - this would force people to think another 24 hours about their reply and that could improve it :)
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.
I think "mean" maintainers in open source are also often a result of burnout, and if he's been working on it for 25 years, perhaps it's time for him to take a break.
[deleted]
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.
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.
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.
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.
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?
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?
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.
As a user I'm a bit wary of installing packages directly from GitHub. The CRAN review process isn't perfect, but it's much less likely that some malicious code accidentally slipped in, or that someone is namesquatting on a popular package name but is not the genuine package. With a random GitHub link I'd feel like I need to do this reviewing work every time myself: investigate who owns the GitHub repository, what their track record is, what recent commits there are and by whom and how reviewed, etc. That's a lot more work than using the heuristic that "CRAN code is probably safe". More mundanely, CRAN typically does a good job with dependencies, and is usually in a working state.
I could see alternate curated repositories from CRAN, but to switch from CRAN I'd still want some kind of curation.
I could see alternate curated repositories from CRAN, but to switch from CRAN I'd still want some kind of curation.
"...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 suspect he may be about to find out.
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..
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.
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.
If I've written and published a new algorithm, and my submission to the open-source community is met with "It sucks, go read up on our guidelines"* , I'm not inclined to spend my free time on a resubmission.
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
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
I agree--I once used a library and noticed that it was missing some functionality. The mailing list had a number of people requesting this functionality. I found an older piece of code with the functionality and updated it to the language of the library. I got license permissions from all the original authors. I submitted it and the maintainers raised some questions about code quality--but one of the maintainers thought there was a workaround and didn't really want to add it. I acted on the code quality issues and the code just sat around and was never accepted and the mailing list still (years later) has people asking for the functionality, but I'm not going to spend more time on it when it seems that outside contributions are not welcome. This was after climbing the barriers to entry of trying to figure out the layout of the project, procedures for submission, etc.
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...
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...
"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."
Citation?
A raw assertion is not helpful.
Citation?
A raw assertion is not helpful.
[deleted]
Typical blog post of the variety "somebody offended me, now I'll deride them in public on my blog".
Just let it go...
Just let it go...
This attitude is gross: open source contributors are not your bitches.
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.
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.
Given that the author IS an open source contributor, DID spot a problem, DID contribute a fix, and therefore DID attempt to take part of the load, three of those lines appear redundant.
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?
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?
I think there are too many words in this article, simply to express that the author had his feelings hurt.
The author points out a common complaint about contributing to open source.
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.
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.
This just made me think, if the maintainer is just part of a process - maybe compilers should be more polite, too.
"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.
"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.
I'd be at the very least nonplussed if an error caused a compiler to say "do your own homework" or the like. There's technical and succinct, and there's unnecessarily rude; that's pretty clearly to one side.
Like it or not, dealing with people effectively and respectfully is an important part of software development.
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
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
In the time it took him to write that post, he could have found his unterminated string and resubmitted.
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.
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.
Although the picture will inevitably not be to everyone's taste, your conclusion seems unwarranted.
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.
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.
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.