[baq]

> a pioneering (but no longer new) PR system

having used gerrit 10 years ago there's nothing about github's PRs that I like more, today.

> code navigation simply in a web browser

this is nice indeed, true.

> You write code, and almost everything works effortlessly.

if only. GHA are a hot mess because somehow we've landed in a local minimum of pretend-YAML-but-actually-shell-js-jinja-python and they have a smaller or bigger outage every other week, for years now.

> why developers like it so much

most everything else is much worse in at least one area and the most important thing it's what everyone uses. no one got fired for using github.

[CamouflagedKiwi]

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.

I've used Gerrit years ago, so wasn't totally unfamiliar, but it was still awkward to use when Go were using it for PRs. Notably that project ended up giving up on it because of the friction for users - and they were probably one of the most likely cases to stick to their guns and use something unusual.

[TheDong]

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

[ncruces]

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

[arccy]

there's certainly a higher rejection rate for github PRs

[foldr]

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.

[PunchyHamster]

correlation, not causation.

Lowest common denominator way will always get worst quality

[arccy]

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.

[CamouflagedKiwi]

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

[miroljub]

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.

[dxdm]

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.

[baq]

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

[foldr]

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.

[baq]

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.

[blibble]

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

[cmrdporcupine]

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.

[blibble]

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

[delusional]

> having used gerrit 10 years ago there's nothing about github's PRs that I like more, today.

I love patch stack review systems. I understand why they're not more popular, they can be a bit harder to understand and more work to craft, but it's just a wonderful experience once you get them. Making my reviews work in phabricator made my patchsets in general so much better, and making my patchsets better have improved my communication skills.

[PunchyHamster]

I used gerrit a bit at work but any time I want to contribute to OSS project requiring to use it I just send a message with bugfix patch applied and leave, it's so much extra effort for drive by contributions that I don't care.

It's fine for code review in a team, not really good in GH-like "a user found a bug, fixed it, and want to send it" contribution scheme