[aDyslecticCrow]

> we recently tried to nudge this behavior by requiring an issue for every PR

I've not maintained or worked much with open source. But i would have assumed this was already common? It reflects how (from my experience) companies work internally with code. Discussion about a feature or a bug is done before writing any code (over lunch, or in a issue thread). We don't want to pay someone to write a feature we don't agree we need, or that collides with future maintenance.

Even before AI, i'd argue the vast majority of code is cheap and simple. But that is what makes it more important than ever to decide what code should exist before someone (well paid) wastes a day or week writing it.

[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.

[serial_dev]

This was / is not my experience. I worked mainly on frontend code, web and mobile app.

As a developer, I got the task, an “order” that something needs to be added. Best case scenario, my product owner / manager came up with it, because they talk to customers and noticed it would be helpful. Worse case scenario, someone else above them told them to do it because “we need it”, and I just hope the product person on my team properly vetted the request. Worst case scenario, the “order” came down to our team, and the managers push to the individual contributors and there is no room for discussion at this point anymore and an arbitrary (made up) deadline that is somehow always unrealistic.

[aDyslecticCrow]

Oof, ye i have heard about this kind of company culture. I think front-end and app development is particularly prone to cheap and dirty iteration. Bugs are cheap and non-consequential. New features are visible, fast to add, and make higher-ups happy.

I work in industrial embedded C. So perhaps i have weird expectations about the level of pedantry. A 10 row code change may take week to discuss, and likely require an open issue and test-case to get through.

At worst, a small 100 row code-change may require a 8000$ independent re-certification of the device before being fully pulled into master.

[LtWorf]

Yeah frontend don't care about correctness. I've seen entire websites go entirely blank because I clicked somewhere and that triggered a js error and that means delete the whole DOM.

[criemen]

> Even before AI, i'd argue the vast majority of code is cheap and simple. But that is what makes it more important than ever to decide what code should exist before someone wastes a day or week writing it.

This 1000%. In my opinion, the biggest part of my job is figuring out what should be built at all, not building what we all eventually agree should be built - that's often pretty easy, AI or no AI.

[gus_massa]

I made a lot of PR for Chez Scheme (and indirectly Racket). For me it's easier to write the code, perhaps because I'm not an English native speaker, but my Spanish is bad too.

Most of my PR are like 30-50 LOC (including comments and tests), with a few very related features, and I have probably a 90-95% merge rate. Sometimes writing the explanation takes a long time. Many times while writing the code I get a lot of small surprises and unexpected corner cases. So most of the time a previous discussion would be too generic to be useful for me and inteligible for the maintainers.

Anyway, my idea is to take only a few hours (4?), perhaps distributed in a few slow days. So if it's not merged it's not a big deal, not hard feelings. Also a short feature is easier to review and modify if necessary.

[IshKebab]

I have worked at a company that required an issue for every PR. It was dumb though. It just meant you made the PR, got shouted at by some checker for not having an issue, create an issue, copy & paste the PR title into the issue, submit the PR, and then the issue gets closer again.

Totally pointless.

> Discussion about a feature or bug is done before writing any code.

Not always. Not all PRs are significant enough to warrant discussion. For example I fixed a copy/paste bug recently where they had `foo_a = foo_b + i;` where it should have been `foo_b = foo_b + i;`. Obvious mistake. One character fix. Why on earth would I bother creating an issue and discussing how to fix it?

[palata]

> We don't want to pay someone to write a feature we don't agree we need

We're talking about open source here, and saying "no" to unpaid, external contributors.

The way I approach it as an external contributor is that if the project is useful to me, I fork it, make my changes, and then open a PR in case the maintainers want to adopt them upstream. They don't have to, it's fine. But I don't have to ask for their opinion in an issue because I will just do what I want in my fork anyway.

[1718627440]

I think the stereotypical open source way is that you modify the code in private to what you want it to be and then upstream that in case it might be useful for others.