[Aurornis]

Requiring an issue per PR makes sense for significant bugs and features, but taken to the extreme it feels arbitrary and pedantic.

I occasionally submit documentation fixes when I find broken docs (outdated commands in the docs, incorrect docs). I’ve had these rejected before because someone insisted I create an issue and have it go through some process first just to submit an obvious 1 line fix.

At the extremes it clouds the issue backlog. You try searching for something and find pages and pages of arbitrary issues that didn’t need to exist other than for someone to get past the gatekeeper.

[giancarlostoro]

I forget the episode its been years but the Talk Python podcast had someone I think from the Django team mention tips on contributing to open source and one of them was start by volunteering to document things, most devs dont do it or want to do it. It forces you to know and understand the codebase and by the time you want to contribute more you know the library better.

[Aurornis]

I actually don’t encourage this. If you find broken docs then contributing a fix is good.

However, writing docs as the starting point for someone’s entry to a project doesn’t produce good results much of the time. You need someone who is more familiar with the project to write the docs. Having the docs written by someone new to the project can lead to some really frustrating docs.

This is even more true now that projects attract junior devs who want to build their resumes and think that documenting can be done by pointing Claude Code at the codebase and demanding it write some docs.

It also encourages bad behavior from devs who think they’re doing a favor for new contributors by leaving the documentation as an exercise for someone else.

[aDyslecticCrow]

You could easily say that docs, comments, and formatting changes don't need issues. The core problem the author is trying to cope with is code changes or features that could deviate the project or scope. I feel it's quite reasonable to set a blanket "issue first" rule for any change beyond like 5 rows of code.

[rendaw]

Or if you need a fix ASAP and go ahead and make the change locally, then want to upstream it later.