> Notably [go] ended up giving up on [gerrit]

That's not accurate. They more or less only use Gerrit still. They started accepting Github PRs, but not really, see https://go.dev/doc/contribute#sending_a_change_github

> You will need a Gerrit account to respond to your reviewers, including to mark feedback as 'Done' if implemented as suggested

The comments are still gerrit, you really shouldn't use Github.

The Go reviewers are also more likely than usual to assume you're incompetent if your PR comes from Github, and the review will accordingly be slower and more likely to be rejected, and none of the go core contributors use the weird github PR flow.

> The Go reviewers are also more likely than usual to assume you're incompetent if your PR comes from Github

I've always done it that way, and never got that feeling.

there's certainly a higher rejection rate for github PRs

That seems unsurprising given that it’s the easiest way for most people to do it. Almost any kind of obstacle will filter out the bottom X% of low effort sludge.

correlation, not causation.

Lowest common denominator way will always get worst quality

sure it's correlation, but the signal-to-noise ratio is low enough that if you send it in via github PR, there's a solid chance of it being ignored for months / years before someone decides to take a look.

Many people confuse competence and dedication.

A competent developer would be more likely to send a PR using the tool with zero friction than to dedicate a few additional hours of his life to create an account and figure out how to use some obscure.

You are making the same mistake of conflating competence and (lack of) dedication.

Most likely, dedication says little about competence, and vice versa. If you do not want to use the tools available to get something done and rather not do the task instead, what does that say about your competence?

I'm not in a position to know or judge this, but I could see how dedication could be a useful proxy for the expected quality a PR and the interaction that will go with it, which could be useful for popular open source projects. Not saying that's necessarily true, just that it's worth considering some maintainers might have anecdotal experiences along that line.

A competent developer wouldn't call gerrit an obscure tool.

This attitude sucks and is pretty close to just being flame bait. There are all kinds of developer who would have no reason to ever have come across it.

A competent developer should be aware of the tools of the trade.

I'm not saying a competent developer should be proficient in using gerrit, but they should know that it isn't an obscure tool - it's a google-sponsored project handling millions of lines of code internally in google and externally. It's like calling golang an obscure language when all you ever did is java or typescript.

It’s silly to assume that someone isn’t competent just because you know about a tool that they don’t know about. The inverse is almost certainly also true.

Is there some kind of Google-centrism at work here? Most devs don’t work at Google or contribute to Google projects, so there is no reason for them to know anything about Gerrit.

> Most devs don’t work at Google or contribute to Google projects, so there is no reason for them to know anything about Gerrit.

Most devs have never worked on Solaris, but if I ask you about solaris and you don't even know what it is, that's a bad sign for how competent a developer you are.

Most devs have never used prolog or haskell or smalltalk seriously, but if they don't know what they are, that means they don't have curiosity about programming language paradigms, and that's a bad sign.

Most competent professional developers do code review and will run into issues with their code review tooling, and so they'll have some curiosity and look into what's out there.

There's no reason for most developers to know random trivia outside of their area of expertise "what compression format does png use by default", but text editors and code review software are fundamental developer tools, so fundamental that every competent developer I know has enough curiosity to know what's out there. Same for programming languages, shells, and operating systems.

These are all ridiculous shibboleths. I know what Solaris is because I’m an old fart. I’ve never used it nor needed to know anything about it. I’d be just as (in)competent if I’d never heard of it.

Oh right. Thanks for the correction - I thought they had moved more to GitHub. Guess not as much as I thought!

> The main thing I like about Github's PRs is that it's a system I'm already familiar with and have a login/account for. It's tedious going to contribute to a project to find I have to sign up for and learn another system.

codeberg supports logging in with GitHub accounts, and the PR interface is exactly the same

you have nothing new to learn!

Yeah and this slavish devotion to keeping the existing (broken imho) PR structure from GH is the one thing I most dislike about Forgejo, but oh well. I still moved my project over to Codeberg.

GH's PR system is semi-tolerable for open source projects. It's downright broken for commercial software teams of any scale.

Like the other commenter: I miss Gerrit and proper comment<->change tracking.

agreed, the github "innovation", i.e. the pull request interface is terrible for anything other than small changes

hopefully codeberg can build on it, and have an "advanced" option