this post was submitted on 20 Mar 2026
24 points (76.1% liked)
Programming
26193 readers
325 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
So basically you're saying that all the comments are welcome, and should be argued, but you have to appoint a person that have the final say on what to merge right?
The problem of deciding what should be merged or blocked, I've mainly made this post to understand that, so saying "#5 or you're crazy" doesn't answer much. But I've probably worded that badly.
If a story gets created, the code will be merged... when it's right. If you're talking OSS, then I am out of my element, but I'll wager there's no universal answer because each code owner sets their own standards.
If there is work that needs to be done, and you are asked to do it, the code will be merged when it's right. I don't decide what to merge, I decide when something is ready to merge.
If you want to merge something and I read it over and reject the PR because you forgot about concurrency, that doesn't mean you don't get to merge, it means that it's not finished baking. And assuming you give a shit about the code your response should be "oh shit, lemme fix that and resubmit" OR "actually this code will never have concurrent access, and here's why."
You're making this process sound adversarial when it isn't. It's a group effort. Everyone wins or loses together.
You're obviously right, you're misunderstanding me. With blocked I didn't meant "forever", I meant until the issues is discussed. I'm merely asking how the reviewer is making the call on what should be addressed before merge in #5
you're really nitpicking my English, which I know is not great, but yeah that's what I was asking, so you use #5 with a single person making the final call on when something is ready.
Absolutely not, I've never said or thought that. But of course development is made of people and computers can only tell you what compiles, not "when it's right" as you say. So of course I'm more curious to understand how to solve situations when you do have conflict, if you don't it's easy.
Mate, the hardest part of software development is communication and autism is ubiquitous — got a touch myself. So I over explain and I'm very specific. But let me make one thing abundantly clear: I don't have time to spend this many words trying to be a pedantic asshole. I have much better things to do with my time. If you don't like my approach, feel free not to engage, but I'm here trying to distill some value for you out of my experience.
Now, I don't put too much stock in up and down votes (and to be clear none of your downvotes is from me — I don't waste time responding to stuff I downvote), but the pattern suggests that what I've said resonates with other developers.
So here's the disconnect: you're worrying about shifting burdens like it's a huge weight, but conflict is exceedingly rare — too rare to worry about. It's a non-consideration.
I'm going to leave it there because I think anything else would just be repeating myself.