I find it frustrating when I get a review request that has nothing complex
when is a change complex enough to warant a review and how do you ensure that no complex change is merged without a review?
Sounds the real issue is that work is poorly defined if it comes to a standstill if no one is available for a 2 minute review.
those 2 minutes reviews are noise at the end of the day, if you ask me, they don’t have a noticeable impact on the reviewers daily performance.
Am a dev at a company that produces code for many different companies and institutions and most of these seem to be problems on a project level to me and not really problems with a code forge.
Stuff happens in the wrong order. You know the PR. Commit 1: ‘Feature.’ Commit 2: ‘fix.’ Commit 3: ‘fix.’ Commit 4: ‘actually fix.’ Commit 5: ‘please.’ Commit 6, made at 11:47 PM on a Thursday: ‘asdfasdf’. This person has a family. This person has hobbies. This person is, at this moment, crying. You don’t want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.
I don’t care how other people use their branches and i don’t want my commits refused, if i can’t commit quickly before leaving my pc than the risk that someone else cannot pickup my work the next day increases. not having something in a shared repository is worse than having it within an ugly commit. And if you are working with atleast one other person, you should not directly push to main or the equivalent of your VCS. the only things we use pre-commit hooks for is running a code formatter. We run commit lints on PRs, because we generate changelogs from commits on PR-Branches and the PR-Branch is the only branch where commits matter to really anyone. but i can run a big chunk of our tests locally, so i can be reasonably sure that a PR-Pipeline won’t yell at me, if i bothered to cleanup my branch before making it someone elses Problem.
PR approval is too boolean. The PR is approved or it’s not approved. Real code review, like real life, lives in the middle. ‘Sure, fine, we’ll deal with it later’ is a legitimate human response and should be a legitimate button. Gerrit has a better model for this. If I weakly approve something as a maintainer, let me flag it for later.
i don’t see what problem this would solve, if a pr introduces an issue or accumulates some form of technical debt, create another issues for that, if you still approve the code to be fit for your main branch. I don’t want stuff to be just thrown onto a “for later”-pile, that should be a conscious decision.
PRs are too inflexible. I don’t need 4 eyes on every change, especially in a universe where LLMs exist. The global GDP lost annually to senior engineers staring at a four-line PR waiting for someone — anyone — to type ‘LGTM’ could fund a moon mission. A nice one. With legroom. Let me customize and more easily control this. If the person is a maintainer and the LLM says its low risk/no risk just let them go.
your seniors don’t drown in dozens of tasks? sounds magical :D
and other than that: Code Reviews are not (only) about checking the code for some vague quality metrics, they help to keep knowledge about the thing we are building fresh in multiple heads and are an opportunity to teach each other or atleast discuss things with a concrete example. without human reviews the risk for knowledge to be stuck in a single head rises.
Stacked PRs are just better. They’re easier to review and understand. They have to be a first-class citizen not an add-on through a tool other than your VCS.
what are stacked PRs? prs depending on one another? i’d rather try to not need those by splitting work into small enough chunks, and if i end up needing those prs, because sometimes we do a bad job with defining those chunks, they should target a feature branch which is later merged into main, when it contains all necessary changes.
A forge shouldn’t do everything. Issue tracking yes. Kanban board, probably not. Wiki? I doubt it. Everything tools always turn into crap. You add features when its easy to add features and then pay the maintenance price for those features forever regardless of their rate of adoption because now someone, somewhere uses them and you are locked in.
as long as i don’t have to create the same issue in multiple places and keep them in sync i don’t care. I kind of agree about the wiki, documentation should be as close to the work as possible and as simple as possible, at work that became either another repo or a subfolder with a bunch of asciidoc and .svgs for modeling work and user handbooks which we render to html. works good, barrier to entry is low so we can keep the docu up to date without much hassle and our customers still get those fancy pdfs they like, depending on the forge the wiki would work simmiliar, but our pipeline for this is essentialy just a bash script and is easy to integrate into whatever tooling the customer requires or whats in use internally.
My local copy of the repo should be a representation of the entire repo, not just the code. I should be able to approve a PR from the same VCS I use to check in the code. I should be able to go through my issues by looking through local files.
maybe you want to use fossil and not git. fossil looks super cool, but the world speaks git, so i sadly don’t have work experience with it.
archive.today/is/ph/fo/… utilized it’s users to ddos atleast one other site earlier this year, not a cool thing.
only on a secondary market in which those companies don’t participate. it’s a paper thin line which keeps trading card game booster packs from beeing gambling in a legal sense
valve has a way to transfer money in your steam wallet into something with real world value: hardware.
you can not trade pokemon cards with nintendo for game cartridges or money, that is the whole distinction, no secondary market required.
small Code Reviews should not warrant an interruption of your work, because not reviewing them should not block anyone. they should be done when someone is actually idling or at a planned time. most of the time i’ll review small changes directly after a daily if someone mentions a small open pr before starting with my actual work, i definitely prefer this to people just merging things and losing the chance to ask questions.