
Ask HN: How do you deal with social media pressure on your GitHub project? - proveanegative
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&#x27;s decisions though the sheer volume of its comments, especially so if many of the people commenting aren&#x27;t involved with the project even as users.<p>From what I have seen so far I can deduce that the technical side of the problem is essentially this:<p>* 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.<p>* Allowing everyone to comment drowns out thoughtful discussion with &quot;plus ones&quot; and &quot;thumbs up&quot; icons, as well as purposefully uncivil comments.<p>* GitHub&#x27;s moderation tools are too weak to moderate the individual comments.<p>When your project faces this pressure how do you act to ensure that meaningful discussion happens and decisions are made that are the best for your actual users and contributors in the long run?
======
mpdehaan2
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
:)

~~~
blumentopf
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.

~~~
mpdehaan2
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 :)

------
gumby
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](https://gcc.gnu.org/news/announcement.html))
to justify it. Nowadays you can fork away with abandon. Take advantage of it.

------
aikah
> 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.

~~~
xmj
The recent witch hunt against projects that don't have Code of Conducts.

'meh' did a masterful job with those:

[https://github.com/opal/opal/issues/941](https://github.com/opal/opal/issues/941)
[https://github.com/opal/opal/issues/942](https://github.com/opal/opal/issues/942)
[https://github.com/opal/opal/issues/945](https://github.com/opal/opal/issues/945)

~~~
jordsmi
My god those comments are a shitshow

~~~
xmj
Meh is a genius in handling those people, you do have to admit that.

~~~
toolz
I don't know that I would go that far. He was very abrasive, whereas his core
message could've been plenty to stop the nonsense he always added a little bit
of aggression to keep the drama going.

If he was a genius, you probably wouldn't ever have known the issue existed.
At least it seems that way to me.

~~~
caseysoftware
But the people who started the attacks researched his profiles and publicized
the entire thing. Their entire goal was public ridicule and getting him
denounced.

If this group of thugs is good at anything, it's getting the word out and the
twitter mobs mobilized.

~~~
xmj
Bingo.

And this is what makes the way he handled it -genius- :-)

------
waxjar
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.

This will solve the issue partly.

~~~
xmj
> This will solve the issue partly.

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.

------
cjbprime
You can temporarily close comments on an issue that's getting a lot of outside
traffic. Usually social media traffic is very bursty like that.

~~~
ta140604
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.

------
bkor
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.

My experience is with Bugzilla btw.

------
click170
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?

------
jakejake
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.

------
ExpiredLink
If it's a hobbyist project you can ignore the "social media pressure". If you
have commercial interests it's probably better to set up your own
issue/feature/bug-tracking system independent of GitHub.

~~~
pvinis
what are some nice ones?

~~~
scrollaway
Gitlab is an excellent self-hostable alternative to github.

[https://about.gitlab.com/](https://about.gitlab.com/)

~~~
xmj
Maybe relevant:

We're bringing GitLab to FreeBSD. :-)

Check the ruby@ list for current status, things left to do, etc.

[https://lists.freebsd.org/pipermail/freebsd-
ruby/2015-July/t...](https://lists.freebsd.org/pipermail/freebsd-
ruby/2015-July/thread.html)

~~~
sytse
Thanks for that effort! Please let us know if we can help in any way.

~~~
xmj
It's all stated on the list ;-)

------
em3rgent0rdr
Too bad GitHub can't weight comments/issues by quality of contributor/user
instead of only providing a binary choice of "only the contributors" vs
"allowing everyone".

~~~
daenney
But how do you measure that quality? Based on amount of contributions? Based
on +1's they've received on comments?

~~~
xmj
Based on lines changed, merge requests accepted/rejected, etc etc.

You know, GitHub developers are quite smart.

They could just write their own weighting algorithm if they wanted to. :-)

~~~
672723074828
Those are absolutely awful metrics to use when measuring a developer's ability
and talent, or the quality of this developer's contributions. They are also
extremely easy to game, too.

~~~
xmj
Yes, that's why I trust GitHub to come up with a (proprietary, unreleased)
algorithm a la PageRank that won't easily be game-able.

------
sytse
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.

------
jerrac
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.

------
datashovel
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.

------
xmj
> When your project faces this pressure how do you act to ensure that
> meaningful discussion happens and decisions are made that are the best for
> your actual users and contributors in the long run?

Make sure you know who your users are.

Keep in touch with them, reach out, do "community building". They will tell
you things about your product/software/system you would otherwise never hear.

That way, you can also filter out issues from known troublestarters as noise,
and, much like in Casablanca, it's a "round up the usual suspects" thing.

You could probably write a bot to filter them out, very similar to the
ggautoblocker whose perl sources *are on GitHub, just, the other way 'round.

~~~
xmj
> You could probably write a bot to filter them out, very similar to the
> ggautoblocker whose perl sources *are on GitHub, just, the other way 'round.

I just did that, actually.

------
buserror
"you got the source, feel free to send a merge request, thanks!"

Problem sorted?

~~~
blowski
Sometimes the issue is that somebody's merge request has been rejected, so not
necessarily.

~~~
buserror
I'm the author/maintainer of simavr:
[https://github.com/buserror/simavr](https://github.com/buserror/simavr)

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...

------
gsudarkoff
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...

------
tomasien
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.

[https://githelp.io/](https://githelp.io/)

~~~
ahmdrefat
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

------
mahouse
Ignore it.

------
logicrime
This sure smells fishy...

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...

~~~
stray
Open source is about the idea that information should be free -- That wondrous
things can be built when we are free to build upon the work of others.

Users are people who benefit from the fact that we've generously offered the
results of our work without expectation of pay.

It has been my experience that those customers/clients who pay the most are
the least demanding. Which is the primary reason that I generally only work on
proprietary systems now.

Because as renumeration approaches zero, hassle approaches infinity.

------
evan_
Maybe this is crazy but you could listen to them, treat their comments as
valid, give a clear indication that you understand what they are saying, and
then seriously consider their concerns?

Too often I see people shut down and go into a kind of "you can't tell me what
to do" coma and lash out. That doesn't solve anything.

~~~
hga
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?

~~~
672723074828
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.

