GitHub issues disabled in "broadcast-channel" project | Hacker News Reader

GitHub issues disabled in "broadcast-channel" project

github.com

19 pointskamilm23 comments

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);

2) if I don’t use the project, I will _never_ use the project and generally question why people are using the project (remarkjs).

Having an issue template is fine. Closing issues that don’t follow the template is (mostly) fine. Taking me to an entirely _different_ website to fill in your form and yelling throughout the whole thing that your bug will be closed if you don’t follow the steps of the time warp _exactly_…is user hostile. I get it that there are entitled users of projects. But by disabling issues or putting a form in front of issue reporting…you have told me that you don’t actually _want_ users, so I’m happy to oblige.

I was looking for an excuse to try Svelte anyway.

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.

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

Because writing good bug reports takes work, and people don't like doing work.

Unfortunately, the practices described in the GP frequently just create even more work...

I’m _happy_ doing work. I’m _also_ happy starting a discussion instead of opening a ticket so we can determine exactly what work would be needed.

But the process should be much more interactive and less WALL than it is.

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

You are mad about an issue you reported being acknowledged and closed hastily as it was already fixed and pending release…

In context, the pending release is a near-complete rewrite that has been in progress for over a year now, and shows few signs of actually being completed. If it does get released, it will likely be an enormous effort to transition from one version to the other.

Like I said, it is absolutely okay for the project maintainers to maintain their project however they like, and if they don't want to maintain two separate bug fixes, that's fair enough. My point was more about the way their communication makes me feel less comfortable and and to contribute back to the project.

1) If that is your mindset, you will likely not contribute anyway.

2) Noone cares if you use my open source project.

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.

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.

The discussion was opened by a guy who made a project "to reject requests from all Russian IPs". Really?

https://github.com/limesquid/express-putin

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?

The downvotes are probably due to editorialising of the title

Thanks!

Does it sound better now?

Looks good to me

> I don't understand the reluctance of looking for an additional maintainer to help curate the issues.

You need to find someone who won't sneak a cryptominer or ransomeware in your library. That's hard.

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.

Finding good maintainers is a lot of work. People who are most eager to become maintainers often aren't good options. It's just as hiring a new employee, and do you want to go through that process and pain to make some guys and girls on the internet happy?

Just as an example, I tried to find a maintainer to take over an OSS project I worked on. A lot of people wanted to take over but didn't understand how to code. They just wanted to project manage, maybe for the sake of their CVs. There was 1 guy I really thought was good because he was helpful, making good PR and so on, then it turns out he is sending racist crap in private to members of the community.

Then there were people who wanted to take ownership so they could do something similar to "rewrite in rust".

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.

Reply on news.ycombinator.com