\documentclass{article}

\usepackage[a4paper]{geometry}

\title{ Merge sooner }

\author{ Sam Wilson }

\date{ 2022 May 3 (Tuesday), 2:14AM }

\begin{document}
\maketitle
\tableofcontents

There was a post\footnote{\url{https://news.ycombinator.com/item?id=31225599}} on Hacker News the other day about the etiquette of merging pull requests, especially ones that are maybe not as good as they could be. I really liked the idea that one should just merge work when it's "good enough" — I think I can be a bit too nit-picking, and often leave reviews about minor stylistic concerns. Far better to merge sooner and follow up with cleanup patches. It's only when cutting releases that the nit-picking should come out.

Of course, the counter argument is that a codebase can become more and more confused, and it be harder for people to understand what's going on (leading to more confusing additions later, which will make the whole thing worse). I guess that's the role of the maintainer: to reign things in, to keep the broad view, to ensure consistency across concerns. Maybe merging everything just makes that job harder, but it also encourages people to contribute, and people are more important than code.

\end{document}
