Lately a number of open source projects has faced tremendous pressure from people coming from Twitter and Reddit to have issues resolved a certain way. Even when you agree with the social media crowd it seems wrong to let it direct your project's decisions though the sheer volume of its comments, especially so if many of the people commenting aren't involved with the project even as users.

From what I have seen so far I can deduce that the technical side of the problem is essentially this:

* Limiting the issues to only the contributors excludes the actual users along with the strangers and encourages the more angry strangers to spam you with duplicate issues.

* Allowing everyone to comment drowns out thoughtful discussion with "plus ones" and "thumbs up" icons, as well as purposefully uncivil comments.

This was basically my life with building Ansible for three years. Given, I loved many aspects of it, but it was really hard and it took a major toll. (clarification: this has post has absolutely nothing to do why I am not working on it anymore)

I've been considering a bit of a blog post on this (particularly the unknown parts of wide scale OSS projects), but basically open source projects get harder as you have more contributors.

Time to review code properly (and to be overly friendly and helpful in doing so) often can completely eat into the ability for you to write and architect code properly, which strips out the ability to do the design that needs to be done. (and as you're doing this - taking maybe 15 minutes per patch, the odds of someone fixing the submission are I would guess about 25% - and you might need to do a couple dozens of these a day).

People can get annoyed at filtering out of decisions unless you overcommunicate at a rate that is probably 5-10x times what is normally expected in normal business conversation. (I was already communicating at a rate that was probably 3-5x what most developers do on the lists, and generally got crucified for it, with myths building up about my character, etc).

Often decisions have no right answer, there's a good and a bad, and either decision will irk someone, and you'll get negative blog posts about what you are doing in either direction. You optimize for the thing that will help the most people, and the one guy who doesn't have his obscure itch scratched will assume you are deliberately ignoring him. You eliminate a problem user so you can concentrate on 1000 people and doing real work, and then others jump all over you after the micro-incident (that they only saw part of).

GitHub makes some things harder -- the issue tracker doesn't have issue templates, so you have to overcommunicate the need to fill out proper templates, and people also throw code at projects prior to asking what the code should be. I love GitHub for the OSS explosion it has enabled, but it is a chaotic way of managing a project as that project gets big.

It also makes it very obvious when a project is buried behind a lot of incomplete contributions, but similarly doesn't provide good tools to sort and manage large numbers of incoming tickets. It makes it very obvious when those ticket numbers build up, and arguments happen on closed tickets.

Twitter is probably one of the worst things, as there's a lot of passive aggressiveness on it. Twitter is an "argument machine". It doesn't provide context, but it does provide a place to rally a mob with pitchforks over the slightest percieved offense, that often should not have been an offense.

Often you don't want people leaving trash on your lawn, but if you edit out the offensive things, the same people claim you are censoring them.

My advice is dont try to acquire users too fast. The "Go" project recently said something like "we had to open source this once it was a certain way along". My conditioning from Red Hat was "do everything in the open", but that was not really something Red Hat always did, as they had a lot of projects with low contribution numbers.

My ultimate feeling is that good projects have good central direction. Contributions can be good, and making a project around a base that encourages lots of shallow contributions can be a very successful strategy for making a successful project, if you do that, you end up doing a lot of custodial work and can't always hit the goals you want to hit.

While it wasn't true in the last 5 years, now I feel the code is more important than the contribution process, and focusing on that allows the users to get a better experience. Users matter a lot - and folks trying to contribute matter a lot - but I don't like the way the inherant focus of contribution turns the creator of a thing into a project manager and a PR manager, and takes away their ability to innovate on the thing.

Being able to work on code is great, but I'd still want to see contribution structured around a mailing list. Strongly encourage talking about code/ideas before submission, but most people will not read it and will submit directly anyway.

I think part of my problem was the barrier to contribution was really low (and that was great) because it was pretty modular at the smaller ends, and we quickly got overwhelmed.
I like to thrash very complex codebases for not being contributor friendly, but the breathing room would have been nice.

I guess there's no clear answer - holding things longer before open sourcing them might help. Making sure you have very high coding standards helps. But eventually you're just going to have that very large number of people.

Most of everyone (95%) are awesome, it's just that the virtue of something being so open exposes you to everyone that might not be - and even those people are probably awesome, the nature of low-bandwidth communication on the internet probably just exposes you to misunderstandings and you end up stressing out over things vs being the friends you normally would.

Ignore what you can - it's a problem when others don't understand this and bug you about every single comment and interaction, and judge you on it. The ratio of complaints to thank you's is not always worth the pay at times, so just make sure you're doing it because you care about it, and find the best way to make it work for you, even if that's moving something to redmine and bitbucket :)

I think parent referred more to contentious issues (e.g. sexism, systemd hate) rather than uncontrollable growth of a project. That said, excellent post, thank you!

The opposite of course are projects with too few contributors that accept any patch out of desperation, be it reasonable or not. (ZFS on Linux comes to mind, it's a super nice community and Brian Behlendorf does a great job as project lead but sometimes features and patches creep in of which I'm wondering why nobody dared saying "no".)

The Linux kernel community solved growth by delegating responsibility to subsystem maintainers. Such a hierarchical model is not supported by GitHub. Also, the kernel community's process of submitting and discussing patches on mailing lists, while somewhat arcane, raises the barrier of entry and keeps at least a portion of the Twitter mob out.

Yeah we'd had contentious issues on the various feature lines (systemd-analogous), absolutely no issues (that I was made aware of) on the -ism lines. The points about various feature items totally hit home though :)

> (...) I'd still want to see contribution structured around a mailing list. Strongly encourage talking about code/ideas before submission, but most people will not read it and will submit directly anyway.

Django enforces this strongly. Anything other than trivial pull requests will be ignored. Contributors are strongly advices to start a discussion on the dev mailing list before working on code and for anything big there's now a formal process for 'Django Enhancement Proposals' (obviously modelled on Python's PEPs)

I didn't know you wrote Ansible, but I just want to say that it is really great. Love that it can be bootstrapped from nothing and that you can bring up another machine that is identical to what you currently have with just a few lines of code.

To not derail this entirely they say that there are two kinds of languages, those nobody use and those people complain about - that is also true of projects in general, so while it may not feel that way people complain because they care (maybe too much and maybe about the wrong things).

You got some great points there but I don't think contributing a change without asking get before is bad even if it misses the project goals. I sometimes need a feature and posting it on mailing lists, etc tasks too long (considering the contribution is only going to be a few lines ~100). If it misses the goal of the project, I don't reallt care. It has fulfiled the licensing agreement (to post code back upstream). I don't care because I'm just going to use my fork and I would have done that anyways if my feature was declined in the mailing list. If the author finds it useful and wants it back upstream, then, I'm happy to have helped.

The great thing about open source is that you can basically do whatever you want with the software and git hub makes that easy by allowing to just fork the repo, hack together the features you want (and post it back upstream).

There is a sense of pressure to merge PRs, though. When you have a lot of open PRs it starts to discourage further contributions. And if you reject a lot of PRs, or if you are too strict about it (i.e. nit-picking their PRs) it can also create a negative atmosphere that discourages further contributions.

Also... when you deal with dependencies in a package manager (like npm dependencies), it is less than ideal to rely on a GitHub fork rather than the module itself.

Personally, I try to merge PRs as often as possible. I aim to keep my open PR count at 0.

If a PR is not quite right (which is often the case), I will clone their fork locally, and edit their commit(s) using git rebase and then merge it.

That way the user is still acknowledged as a contributor on GitHub (and they can see both of our names/profile pictures next to the commit message). Then I make a comment explaining why I edited their commit(s) on the pull request itself or the issue page. That keeps everyone happy and encourages further contribution.

It's not always practical to do this though but it feels natural in many cases.

So quickly outline the reason why it's not ready for merge, and if the contributor doesn't respond in a reasonable window you can reject the PR with a clear conscience. If someone else takes an interest and offers to clean up the code, you can reopen the PR.

When I first started using Ansible, the fact that you replied directly to many of my Google Group posts was what really sold me on it. So, from a users perspective, the time you spent on that was well spent. Thanks for that! Ansible has saved me a ton of time spent on tedious and annoying tasks.

Personally, I think the balance between giving good user support and spending enough time on actual development work is really really hard to figure out. But one way projects could help it work better, is make sure it's very clear how users should get support, and how much they can expect. And I have yet to see any project do that. If it was clear, then you could politely point newbies who just don't know better at the support doc. People like me who spend a lot of time making sure our requests won't waste time, would have solid guidance on how to do that. And jerks who are just wasting time could be politely pointed at the doc and then ignored when they don't follow it.

You (or they, depending on how you consider things) have a simple tool to solve the problem: let them fork and do what they want.

It sounds like I'm trivializing the issue but I"m not (see below). Take a kindly approach: "Clearly I have a disagreement as to the right way to proceed so let's stop arguing and both go down our respective paths." Don't worry about the obnoxious folks: be kind and take them at their word. If they pick up the ball, perhaps they will be proven right and you'll switch, perhaps they'll be proven wrong and that experiment won't have hurt your project, or perhaps they'll be proven trolls (by not picking up the ball), in which case you can saefly ignore them.

And when I say this is a simple tool: it took me months to arrange the first "legitimate" (in the sense that it was accepted as a mainstream activiy) open source fork, which was GCC back in 1997. Until then forking a project while done (often companies would hack something unsupportable into, say, gdb), was considered grossly dangerous. It took literally months of discussion to split egcs off from mainline gcc (and to become, in fact, mainline gcc). I had to write a really long, careful message (https://gcc.gnu.org/news/announcement.html) to justify it. Nowadays you can fork away with abandon. Take advantage of it.

> Lately a number of open source projects has faced tremendous pressure from people coming from Twitter and Reddit to have issues resolved a certain way.

Can you point to a specific example? the only things I have seen is some brigading and cabal to pressure a project owner to remove a contributor from a project, but it was akin to a lynch mob, not related with programming in any way.

If 'meh' had used a real name they probably would have attacked him pretty early in that conversation - going after his job or his reputation in other areas.

The shield of a pseudonym allowed him to stand strong and forced his opponents to engage with him, resulting in this masterful display of defeating an SJW mob. This is a lesson to us all, and a reminder of what is no longer possible with "real name" policies.

Those threads prove to me that it has become very time and effort efficient to mob swarm things on the internet. You can spend five minutes a day making some project's life miserable.

When you see "I got a message on Google plus from one of my fellow dev buddies from the F# community linking this discussion." you pretty much know that the mob doesn't have any real interest in your project other than to spend a couple of minutes to show their outrage. This is basically why people still put a lot more weight on letters, fax, and phone calls.

I'm at a loss for words. I don't know whether to be angry that there's discrimination or the person playing the victim card and demanding change on a github out of all places. When the hell did github issues tracker turn into an all out debate forum?

It's really sad that it seems like the developer in question wasn't even speaking from a place of hate. Really unfortunate that the reaction is basically the pressure others to participate in a silent treatment of the individual.

This is one example I had in mind when I made this thread; the issue that the grandparent mentions is another. I have seen a similar scenario play out with a few smaller projects' repositories but I am reluctant to mention them.

There is also good-natured but meaningless noise like https://github.com/gogits/gogs/issues/5. I believe this kind of support, while flattering at first, ultimately puts undue pressure on the volunteer contributor. On the plus side, the comments come from people using the project.

Perhaps GitHub was wrong to get rid of the upvote button on issues unconditionally. Having the option to enable it would probably have helped the Gogs case.

I think GitHub needs a "+1" button for issues. It'll give maintainers some insight as to what priority to give an issue, without spamming them with e-mails. Asking users not to comment with comments such as "+1", or even turning off comments, hides this information.

On the contrary; it will turn the whole thing into something that can be gamed even better by those who are good at rallying, organizing mobs, and shaming people into doing what the mob organizers can't do on their own.

Exactly. It's an outrage machine, people who participate mostly want to get their daily fix of feeling that they're fighting for a good cause - and if you lay low for a few days or a couple of weeks, few if any will be persistent enough to bug you after that, as the focus will shift elsewhere.

You may or may not want to issue a polite and carefully-worded statement, but don't cave in - something like "we've heard you and understand your position, thanks for letting us know".

It might be different when the issue is used in intra-project political fight (like two companies competing for control over the project), but for your average Twitter raid that should be enough.

Do not engage further, do not fight them, they are just self-righteous trolls - so, just don't feed them.

Delete/hide the comments and a public announcement on the bug what types of comments are acceptable/unacceptable.

As someone else said, it is usually very obvious. Many comments within 24 hours on a bug that is usually bike shed worthy.

Bugs comments should be technical in nature. Basically no (endless) discussion _if_ something should (not) be done. It should be about _how_ to do something (implement/fix bug/etc).

The deleting (hiding for anyone but admins) is usually pretty effective. Once they understand that you have way too much time on your hands, then they'll stop pretty quickly.

What's important is not to get aggressive though. Try turning the attention into something positive and give some tips (how things work and how to get something done). E.g. sometimes bugs do get forgotten and some attention will get them fixed. But that doesn't need 10-15 comments after eachother.

Maybe what Github needs is a way to put an issue or all issues for a project into Review Mode where every comment posted to the issue by a non-contributor must be reviewed and accepted by project members before it is posted. This would allow non-contributors to post comments of value (as decided by the contributors), and would make it harder for trolls to spam the discussion.

This would place additional overhead on the project maintainers, but IMO this is more ideal because emails from trolls and people not contributing to the conversation can easily be ignored by filtering out messages from that Github user.

It would not be perfect but it might be better than what we currently have?

Developing a thick skin and not feeling like every request is a life-or-death situation - this is what you need to have. You have to take the input and make adjustments as necessary, but continue to steer the project toward your vision. You also should decide how much time you will devote to the project and then not go over to avoid burnout or interfering with your life/work.

My most popular product at the moment has maybe 150k installs and I could spend the rest of my life trying to appease every request. I can only imagine a massively successful software project must be a deluge of requests.

At GitLab we're considering a feature that will reduce the noise of +1's and other emoji's, we're been planning it for a while but you could compare it to Slack's function: leaving an emoji doesn't generate a comment.

Depending on the issues effected, I'd shut off comments/issues until the social media storm is over.

If it's a longer term issue, then throw up a Discourse/forum instance somewhere and close any effected issues with a comment along the lines of "go talk about it here, where you won't negatively effect development work."

You could also just turn off GitHub issues and move to a different system. Maybe make all new issues go into a forum/google group, and then when a valid issue comes along, allow a contributor to create a issue on GitHub.

Off topic: I think there's a huge opportunity for someone to shake up how support requests/bug reports/issues/tickets/etc. work. Part of that would be building tools that help developers manage support requests while still being newbie friendly. As well as issues like social media pressure. If anyone's working on something like that, I'd love to give feedback. I've had ideas on the subject, but haven't had the time to pursue it myself.

I have always felt that the "uncivil" parts are typically coming from people who have to depend on others to accomplish what they want. There has to be a certain amount of anxiety that comes from being asked to do something that you may not know how to do yourself. e.g. Someone who is not a developer themselves.

On the other hand, if you notice alot of developers complaining, my first thought would be that the code may not be modular enough that the developer feels they can comfortably make changes themselves without knowing what it will do to the overall code base.

Wherever there is reasonable dissent, it seems it would be a perfect opportunity to reorganize that part of the code so that many different opinions can be happy about the end result.

I've had to refuse some merge requests, I did it by mostly ignoring them, or explaining that it looks like a very large patch for a something that isn't necessarily wanted...
Also I factor in the fact /I/ will have to maintain that patch in the future, as the contributor will likely disappear to other interests sooner or later, so if I don't like it, ultimately it's /my/ choice, even if it doesn't come down to a technical point...

A good 'test' of a merge request is to see if the author is willing to make changes that you request.. It is a very good filter for 'motivation'; if the author doesn't reply, well, that's a merge request I'll close it 6 month next time I go down the list...

Managing scale is managing scale. There are numerous business books written on this subject. In a nutshell: build a scalable org structure (delegate, get yourself out of the loop when possible), explicitly define policies and processes, establish quality controls and do NOT compromise on quality, invest in communication and training...

I saw this as a possible helpful tool. They actually sent some un-solicited emails to folks running large projects (which they definitely should not have done but seem to feel bad about) so it got a lot of bad will off the bat, but it seems helpful.

Thank you for mentioning it, and yes we've done this mistake and we've apologized for everyone. And GitHelp is about open source support, where we encourage users to take of all thier support request from GitHub and have them on GitHelp where they can have a better more professinal support services than just a simple Q&A

If you're running an open source project and users are pouring into the cracks to say that they don't like something, it's an obvious sign of what they want. Open-source is supposed to be about the community, maybe you should try listening harder to them.

Users aren't just sheep that use your product, they're an integral part of the entire process, equal in value to the developers.

edit: Who woulda thought that HN devs didn't give a shit about users? As if we didn't know that already...

On the other hand, forking is completely legit. It happened already in the past and will happen in the future, for major disagreements. Open source mantainers don't owe it to the community, if the community ultimately does not behave.

What if their comments are not "valid"? What if their agenda is stirring up shit, not the health of your project at all? To take an extreme but existing example (urbit), what if they want your project to die because they (think) they don't like you, a person working on the project?

A bad thing to do is to start thinking such things to begin with. Just because somebody expresses an idea that you personally disagree with it does not mean that they are "trolling", it does not mean that the idea is "invalid", it does not mean that they're trying to "stir up shit", and it does not mean that they're trying to "kill" an open source project.

Always respond to their concerns with professionalism, courtesy, and tact.

The absolute worst thing to do is to start censoring them. I've seen this happen with a number of GitHub projects in the past. People occasionally come along with ideas that some, or sometimes even just one, of the core contributors does not agree with. Even when the newcomers are participating in good faith, I've seen intolerant GitHub project leaders start deleting perfectly good comments, closing perfectly valid issues, rejecting perfectly good pull requests, deleting perfectly good wiki content, and otherwise engaging in behavior that is much more harmful than anything the newcomer could managed to have engaged in.

When I see that happening to new contributors, especially when it's a small project involved, then I know it's time to move on from that project, both as a user and contributor. I refuse to be associated with such nonsense.

I think you're assuming a lot about what's going on on the receiving end of those comments. You're assuming that what you suggest is even an option for them, and that the people who don't devote hours (if not days) per week to doing what you suggest are avoiding it out of selfishness or ignorance or laziness. You may also be vastly overestimating the signal to noise ratio of that input. It's true that some people are just crappy maintainers, but there's rarely enough information to make that determination.

Ultimately, most of these maintainers are volunteers doing what they're doing in their spare time out of love for their craft, and they have no social or professional obligation to let other people dictate the direction of their project. The nice thing about open source is that if there is a critical mass of users who are unsatisfied with the state of the world, they can fork it and take it in the direction that they want. Yes, "just fork it" is often used as a cliched excuse for shutting down conflicting viewpoints, but it's such an effective excuse because it's also a true statement.

What if there isn't a critical mass? What if there's an important project which has received and ignored perfectly reasonable user requests, or even patches that "just have to be merged", but there's no critical mass for forking? Sadly, that's how pretty much everything else in the world works as well. Like democracy and capitalism, it's the worst system in the world except for every other one. Everybody has a laundry list of complaints about their most-used software, and has thought to themselves, "if only they would change this one thing", "if only they would just merge my patch", "if only they would listen to me", then everything would be great. What the "if only's" of the world don't see is that for every popular project, there are dozens if not hundreds or thousands or millions of people who each have their own "if only" which in many cases are contradictory if not outright wrong. If someone just doesn't have time to work on their passion project and drink from that firehose at the same time, I do not judge them for choosing to focus on their own code.

Yeah I'm not really 100% in agreement with my own comment to be honest, it ignores the very real existance of malicious trolls for one, but it just annoyed me that every single comment was assuming a standpoint of "assume anyone who disagrees with you is wrong".

In the context of the original, "tremendous pressure from people coming from Twitter and Reddit to have issues resolved a certain way", i.e. a social media campaign to use politics vs. "merit" in making a particular decision, even if the decision is correct as the original notes, I'm willing to label that "input" as illegitimate, and dismiss it (politely or not).

It's very dangerous to give into that sort of pressure, for the next "request" might be very wrong. Although depending on the nature of the situation, that can be even more dangerous, since it has been demonstrated this can cost you your job or career.

(I'm afraid I'm come to the conclusion that I'm going to have to do future projects under a pseudonym, I have unPC discussion comments going back to the '80s that are still on-line last time I checked, all the way to this 10 days ago: https://news.ycombinator.com/item?id=9815052 .)