Hacker News Reader

I don’t find anything wrong with the authors approach. I just think he should make it clear that he’s not interested in issues or PRs on the project readme or contribution guide. It’s hard to have it both ways - where you say issues and PRs are welcome but say no when someone reports or makes a contribution.

I agree that making it clear is important, and I think I edited my post at the same time as your comment to say the same.

However, I think I still disagree with closing issues, particularly with a bot, even if expectations are set. On GitHub, I think labeling the issue is more appropriate. Labeling it as "maintainer-wont-fix-contributions-welcome" with a detailed "I will only accept a PR if these conditions are met" in the README is much better than just swatting away things by closing and saying "won't fix" or "this is not a bug". If PRs and issues truly will be ignored, then that really needs to be explicitly stated. Because otherwise, why even open source or release it? I have seen quite a few presentations with "I maintain all these projects" instead of the truth of "I open sourced all of these personal projects". There is a difference.

> If PRs and issues truly will be ignored, then that really needs to be explicitly stated.

No it doesnt. No one owes anything to you

> Because otherwise, why even open source or release it?

Because they can.

Society generally disagrees that unclear or unresponsive communication is welcomed. If someone speaks to me, I believe giving and them expecting a respectful response is not entitlement on their part.

> Because they can.

That's not really an answer to basically any question. Yes, a person can do anything, but actions also have consequences. Also, frustration is a legitimate emotion for anyone. It's okay for someone to be frustrated and admit so in a respectful manner. Being frustrated does not make one an evil or entitled person by default.

Lastly, there are different approaches and perspectives, which is also fine. For open source development, there is no one true approach that everyone is going to agree with. But I do think clear communication will reduce a lot of friction no matter the approach.

I once came across a project where the maintainer clearly stated that they will never adjust the license. Is it frustrating? Yes. Do I disagree? Yes. But it's their choice, and they clearly stated it. So I grunt to myself and move on.

> Society generally disagrees that unclear or unresponsive communication is welcomed. If someone speaks to me, I believe giving and them expecting a respectful response is not entitlement on their part.

That only works because meatspace limits the number of people who can impinge on your time.

That's not true for Github. Any maintainer is heavily outnumbered by the number of people who can file issues against their project.

I blame the fact that we centralized bug reporting. Back when everybody had to create an account on a different Bugzilla, there was enough friction that you had to want to file that bug report very badly--especially if there was a 24 hour waiting period to sign up. That kept the ratio under control so the maintainers weren't too outnumbered.

(Side note: I suspect there is also some level of "Filing bug reports on Github is a corporate metric" somewhere also creating extra static.)

The amount of people who read through a README is probably in the single digit percentage of users who post issues (judging by the fact that so many issues have their resolution in part of the README).

The number of people (especially those who post issues, not PRs necessarily) who read a contribution guide is probably less than 1%.

GitHub issue templates can help in that regard, but it's still pretty minimal the amount of work 80% of people who post issues will put in towards solving it themselves first.

Normally if the README contains the restrictions on contribution and PRs right at the top I think it should catch everyone’s attention (well, hopefully…).

IMHO, the ideal solution is for GitHub to allow restrictions on issues and PRs for public repositories. You could always make the repo private though. I don’t think there is a restriction on private repo’s right now in GitHub.

> because the filing of an issue is not a request to fix

Great phrase, this summarizes the point very well!

Exactly. A bug report is just that, a report. It increases the knowledge base of what problems exist in the project so that everyone can know.

It doesn't mean it has to be fixed. Not everything can always be done. So if it remains open, it's simply documentation of a problem that still exists. Closing it because some time passed is dishonest, if the problem still exists.

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

Is it a bug report? In that case I agree that it is irritating.

Is it a feature request? Then your mistake is to spend days on crafting feature request. I prefer to make simple feature request and spend more effort if it is provisionally accepted.

> It just means that users get a false sense of the tool's maintainability, reliability, etc. by looking at a "clean" issue listing only to find out that tons of issues still exist.

I look also at recently closed ones - if stalebot is present then I escape immediately.

> The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate

that is entirely appropriate response, maintainers are not obligated to fix bugs (unless they are under some support contract).

> On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source.

what is the problem here?

> > On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source.

> what is the problem here?

My personal issue with it is that it is misleading. I feel there is a difference between "I am the maintainer for these open source projects" and "I open sourced these personal projects" if one doesn't really maintain, in a community sense, the projects. It's akin to resume padding.

OK, if someone abandons open source project and claims to be developing it then I see a problem.

(though open sourcing project and not accepting PRs or even issues is fine, if it is actually maintained)

Agreed. I think this just revolves around clear communication and expectation setting. Just too often it is all too implicit and ad-hoc, where frustration easily brews on both sides.

It's like wet towels and mildew. Lol. Don't wet them if you're not going to dry them or hang them up. (Disclaimer: I didn't heavily think through this analogy.)

Whether they are actually maintaining or just "padding" is quickly revealed by visiting the repositories of the developer who claims so, or? I can also claim on my resume that I am a world famous actor, but my mostly blank IMDb page will quickly tell another story.

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

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

The key thing is that your frustration doesn’t entitle you to anything.

The best thing to do is to contact the maintainer first before you do the work. Saves a lot of frustration. But I feel that people don’t want to hear no and need an excuse to do the work anyway because they like doing it.

The ‘no’ that eventually is / will be communicated shattered the illusion that they are helpful/contributing.

For me the whole “no” topic is all about setting personal boundaries. Maintainers have to deal with the same drama as mostly women face when dealing with unwanted attention.

But to me it’s 100% this ingrain sense of mostly men feeling so entitled to basically anything is so toxic.

“No” is a perfect antidote to that toxicity.

> The key thing is that your frustration doesn’t entitle you to anything.

Well see, I never said that.

However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations.

> The best thing to do is to contact the maintainer first before you do the work

That's rarely possible without filing an issue, which will apparently be immediately closed anyway, and I think the better solution is for the README to merely state the expectations.

GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only.

> However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations.

Why? No they don't deserve anything. Unsolicited communication is unsolicited.

>GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only.

Why should anyone bother. It doesn't mean anything

I was going to argue your comment, but you don’t deserve it.

There is a middle ground where sometimes the maintainer does accept a PR and sometimes they don't for whatever reasons they have.

Maybe it's all clearer to you, but this isn't about you and what you want or need. This is what about maintainers need to keep their sanity and not abandon the project(s) all together.

Be happy with what you get, accept rejection / disagreement, especially if nobody asked for anything. And most of all, just accept the ambiguity. Learn to live with it.

I maintain that just contacting developers first before making a change/feature + PR is the best way possible to at least have some chance that the PR will be merged.