Live data from Hacker News

GitHub issues disabled in "broadcast-channel" project

github.com

1–10 of 25 posts

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

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

The downvotes are probably due to editorialising of the title

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

#4
post #3
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?

The downvotes are probably due to editorialising of the title

Thanks!

Does it sound better now?

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

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

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

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

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

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.

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

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

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

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

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

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.

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

#10
post #7
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?

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

Post reply on HN