Hacker News Reader

Comment by chrsig | Hacker News Reader

> Certainly with the volume of PR's (100+) and Issues (5k+), the current Maintainers have their hands full. Decisions will have to be made, and priorities established. While an argument may be made that we need more Maintainers, this is not an overnight solution. A Maintainer needs to really "own" the project, and has to have substantial knowledge of the code inside-out.

I think one of the big problems is that decisions aren't being made. Issues, proposals, PRs, etc. get ignored. Ignoring is not a decision, it's the absence of a decision.

It's fine if they don't want to accept/fix/invest/etc in whatever issue a contributor is raising, but by not providing a rationale, the community just gets left in the dark without any idea how to proceed.

View on HN

FYI there is a weekly review of a subset of open proposals here: https://github.com/golang/go/issues/33502

I'm aware. There's no timeline for when a proposal may actually be considered. It certainly isn't submission order. So proposals sit around for an indefinite amount of time before entering into the process to give them a definitive decision.

Is this scenario better managed in other language projects?

I've made contributions to Rust repos and it was a great experience, they helped me along and were very quick with responses. I never even considered it for Go because the community shot down every idea I had.

I'm a maintainer of some smaller open source projects -- you have to consider it from the project owner's point of view. To say they "shoot down ideas" is a negative way of saying it, but from their point of view they're carefully selecting and designing features and code that fit the design philosophy of the language. If the Go developers included every idea that users submitted (and there are many! -- I read the mailing lists), the language and standard libraries would be a sprawling and incoherent pile.

I imagine it varies wildly based on the project. How any other project behaves doesn't change the experience of working with the go project.

Comparing go to itself, I feel like they've lost some steam and are coping with the ecosystem steadily growing. I can't say for sure if that's the case, and I can have a lot of empathy for anyone just feeling exhausted all the time these days. That doesn't change the experience on the trying-to-contribute side of the interaction though.

Reply on news.ycombinator.com