Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub issues disabled in "broadcast-channel" project

github.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: GitHub issues disabled in "broadcast-channel" project

#11

Post by orf »

halostatue wrote: post #9

I’ve had extremely frustrating and contentious discussions with maintainers who choose to put forms in front of their issues in their repositories. It’s bad enough that 1) if I use the project and can’t easily switch from it, I will simply not contribute in any way to the project from that point forward (I’ve filed two issues with Vue.js projects; I will not be filing any more, because they are horribly user-hostile)…

Look at the quality of issues on both large project’s GitHub issues and mailing list (or equivalent). A significant portion of them are crap. Like, worse than crap. Just “help (first line of stack trace)” or even a photo from a phone of a laptop screen showing a windows CLI with some error text on it.

I can’t comprehend how people would write these issues. But they do. And it sucks.

Re: GitHub issues disabled in "broadcast-channel" project

#12

Post by MrJohz »

halostatue wrote: post #9

I’ve had extremely frustrating and contentious discussions with maintainers who choose to put forms in front of their issues in their repositories. It’s bad enough that 1) if I use the project and can’t easily switch from it, I will simply not contribute in any way to the project from that point forward (I’ve filed two issues with Vue.js projects; I will not be filing any more, because they are horribly user-hostile)…

> forms [...] Vue.js

Vuetify? I spent ages putting together an issue there, only for it to be closed almost immediately because it had already been fixed in the v3 alpha branch. That's great, but I can't use the v3 alpha branch because it's still an alpha version that's missing half the features...

It's obviously always the maintainer's right to handle their project in the manner that they think works best for them. My dependence on their project is to a certain extent a burden on them, and I'm grateful to people who are willing to put time into maintaining projects that I (and moreover the company I work for) regularly use.

However, I do think the open source community works much better in terms of reciprocity. When I can create an issue and get some feedback there, there's a good chance I'll also try and fix the problem myself, because to me that seems like the responsible thing to do as someone who depends on open source code. If I have the feeling that the maintainers just don't care about my feedback, then I'm just going to be more loathe to contribute.

And specifically when it comes to Vuetify, much like yourself, I'm now in the situation where I'm looking to remove it from projects I'd previously been using it in, because when future problems come up, I think it'll be more of a maintenance burden than just solving the problem myself.

Re: GitHub issues disabled in "broadcast-channel" project

#14

Post by [deleted] »

orf wrote: post #11
halostatue wrote: post #9

I’ve had extremely frustrating and contentious discussions with maintainers who choose to put forms in front of their issues in their repositories. It’s bad enough that 1) if I use the project and can’t easily switch from it, I will simply not contribute in any way to the project from that point forward (I’ve filed two issues with Vue.js projects; I will not be filing any more, because they are horribly user-hostile)…

Look at the quality of issues on both large project’s GitHub issues and mailing list (or equivalent). A significant portion of them are crap. Like, worse than crap. Just “help (first line of stack trace)” or even a photo from a phone of a laptop screen showing a windows CLI with some error text on it. I can’t comprehend how people would write these issues. But they do. And it sucks.

[deleted]

Re: GitHub issues disabled in "broadcast-channel" project

#15

Post by vips7L »

bob1029 wrote: post #10
rurban wrote: post #7

Earlier quoted context omitted.

accepting only pull-requests and discussions is fine if the maintainer can live with it. apparently the js ecosystem is a shithole. I couldn't, as a prefer silly bug reports over none. but I have disabled many issues on forks. issues should go upstream.

> apparently the js ecosystem is a shithole. The latest standards-compliant JS is really nice to work with (i.e. vanilla). You don't need an "ecosystem".

Too bad 50% of my users are still running internet explorer.

Re: GitHub issues disabled in "broadcast-channel" project

#17

Post by agilob »

kamilm wrote: post #2

While I understand the frustration caused by people not respecting maintainer's time, I don't understand the reluctance of looking for an additional maintainer to help curate the issues. What's your take on this? Do you have any experience in this area?

If there was another maintainer willing to help they would open enough helpful PRs to get noticed and be granted a privileged status.

I review issues on openapi-generator and I can easily say 90% of them are result of user not reading documentation, unrelated shit like "how do I x in docker/gradle/maven". I think author here has strong points and I support him as a maintainer, but i would also be also annoyed as a user.

Re: GitHub issues disabled in "broadcast-channel" project

#18

Post by realPubkey »

Maintainer of the repo here.

I disabled the issues of most of my projects. Over the years I have observed that people who actually contribute value, do not need the issue section. They will directly open a PR with a change or at least some code that explains their problem.

People started arguing with me about this topic. But these where never the people that actually contributed to any open source project that was not their own, so I do not care at all.

I opened the discussion section so people can actually discuss there, without wasting the time of the maintainer.

Re: GitHub issues disabled in "broadcast-channel" project

#19

Post by alexeldeib »

sebazzz wrote: post #13

Slightly related to this, I can't understand why Github doesn't offer a "read-only" mode for issues. Once a repo is archived or issues are disabled, all issues are then unavailable. This is super annoying as it causes many broken links.

I think it’s possible to restrict issues by privileges on the repo, so you wouldn’t get new issues from random people, anyway.
Post reply on HN