I kind of with the sentiment. Review pre merge though, but only block the merge if there are serious faults. Otherwise, merge the code and have the author address issues after the merge. Get the value to production

[–] Doveux@pawb.social 2 points 1 year ago (1 children)

I'm with you. I've worked on a few teams, one of the first was a company where two teams were contributing code changes to the same product. The other team "owned" it and as a result it took ages, sometimes months, to get code changes merged. It meant more time was spent just rebasing (because merging wasn't "clean") than working on the actual feature.

My current role, we just do TDD, pair programming, and trunk-based development. We have a release process that involves manual testing before live deployment. Features that aren't ready for live are turned off by feature flags. It's quick and efficient.

Fundamentally I think the issue is the right tool for the job. Code doesn't need to be managed the same way in a company as it does in an open-source project.

[–] zalgotext@sh.itjust.works 2 points 1 year ago

Code doesn't need to be managed the same way in a company as it does in an open-source project.

Open-source projects are usually longer lived more maintainable, more stable, and more useful than any closed source code I've ever worked on for a company. Partially because they're not under contract deadlines which create pressure to "deliver value" by a certain date, but still. Might be helpful for companies to consider adopting practices the open-source community has shown to work, rather than inventing their own.

load more comments (13 replies)