We had a process at one company where you had to create an issue before filing a PR. I found it most non-sensical and introducing friction for no good reason. Very surprised to see the author suggesting it in the article.

Review is indeed the main bottleneck now for open source, and we need to solve it. Introducing more friction is hardly helping.

The author is describing a method for turning a low trust/no trust environment into a slightly higher trust environment.

A company is usually already a high-trust environment, where people use real names and have real reputations. So creating an issue cannot serve the purpose of increasing trust.

I think the point that he is making is that the additional friction is a good thing and necessary in this case because it's an open source project. It's too easy to do drive-by PRs that don't actually provide value and just eat up review cycles. The issue requirement simply ensures that the requester actually is invested and cares enough about this to get approval before starting work on it.

I can see why that doesn't sound great particularly on a team where everyone knows each other and is working together but it totally makes sense for me if I were maintaining a project that was large enough to get a lot of low-effort PRs coming into it.

Are there other companies? Where you are submitting PRs that solve no known problem?

We had that process too, and I insisted on it. Any PR not matched to one or more issues gets automatically rejected. The friction this injects ensures people are not wasting company resources bikeshedding.

I'm a world champion bikeshedder, and I both hated this policy and insisted we keep it.

[dead]