Hacker News new | ask | show | jobs
by narrowtux 1289 days ago
> As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed.

The article also discusses that. Of course there are better ways to do this than just closing it wihtout comment, even though the end result is still saying "no" to it.

I have open-sourced a library that I wrote for an in-production app at work, and it got a little too popular for me to handle like most open source "consumers" (even though they don't pay me) expect.

Every time there's a feature/pull request, I not only have to think about if the code is correct, but also if it would introduce breaking changes in the way it is used in that production app.

It's very mentally draining to visit the issues page of that repository, because it's full of people needing help or wanting to contribute work. But I can't handle them all within an acceptable timespan.

Every few months I take half an hour to clean up there, and then the issues list is already filled with disgruntled users.

> The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues.

I agree in hindsight that it probably would've been better to just turn off the pull requests feature when creating a repository if you can't commit yourself to the potential workload it creates.

> Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication.

Most of the time you don't realize that you really can't handle all that workload when you're still in the "honeymoon" phase of the thing you're open-sourcing. What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?

1 comments

> > As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed.

> The article also discusses that

They mention that but they don't really discuss it, and I disagree with the conclusion and advice.

GitHub allows disabling issues altogether. Just do that snd save everyone trouble.

> What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?

My thoughts are my overall opinion and approach: clear communication. Just update the README, appropriately comment on issues that are closed as a result, and maybe even disable issues.

This is slightly off-topic, but reading your responses on this thread just rub me the wrong way. You're acting like you're entitled for open-source devs to support you and value your contributions for the sole reason that they might put a line on their resume?

As if you had the right to be angry at somebody just because they had the audacity to open source code and struggling with maintaining it.

Of course it is simple to say "communicate this clearly" in hindsight. And I kind of did that. Still there are users who expect more from me than I can give.

Yet again, I have not once indicated anger (what?) or entitlement. Yes, I have been frustrated at unclear communication, and I do not consider the expectation of clear communication to be entitlement.

I am moving towards open sourcing some projects (already have), and I am trying to think about this myself. I have not landed on a solution I am happy with or even followed my own README advice, yet. In my experience, it is very pleasant to work in repositories that set good expectations with clear communication. But it has been frustrating to interact with a "contributions welcome" repository where issues are swatted down like flies, especially when the reporter offers to debug and even help contribute a fix. I just stop going there, and I would have preferred to just have such culture be clear upfront.

I have even started considering offering paid support for important issues to be fixed, and I am trying to take an active approach in contributing to projects I like using, so I really don't think I approach things as you imply.

Edit: Also to be clear, I am not speaking to anyone specifically. These are general sentiments.