4 ms·
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 pro
by CamouflagedKiwi 11mo ago
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 11mo ago> 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 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 11mo ago> 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 11mo agothere's certainly a higher rejection rate for github PRs
- foldr 11mo agoThat 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 11mo agocorrelation, not causation. Lowest common denominator way will always get worst quality
- arccy 11mo agosure 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.
- miroljub 11mo agoMany 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.
- baq 11mo agoA competent developer wouldn't call gerrit an obscure tool.
- foldr 11mo agoThis 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 11mo agoA 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.
- foldr 11mo agoIt’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.
- TheDong 11mo ago> 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.
- CamouflagedKiwi 11mo agoOh right. Thanks for the correction - I thought they had moved more to GitHub. Guess not as much as I thought!
- blibble 11mo ago> 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 11mo agoYeah 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 11mo agoagreed, 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