[ragall]

> Then make it private

You don't get to decide that.

> It's a reckless disregard of other people's time and nerves. Build labyrinths and scatter them around the internet. Leave manholes uncovered.

That's a *you* problem, because you have wrong expectations.

> Then close bug tracker and post "Abandoned" on the front page.

You don't get to decide that.

> Then say so and then reject them. That's what PR review means. I don't have a problem with rejected PRs. I have a problem with ignored PRs.

Another case of you having wrong expectations. Like in networking, you should put a timeout on all requests. For all practical purposes a request that times out is to be treated the same as a rejection.

[M95D]

> [...] you have wrong expectations.

I did. (Past tense.) I'm calibrated now.

> You don't get to decide that.

You're exactly right. I only get to decide what I do with my own toys. And I've decided I won't waste any of my time. If you (plural) can't write a one line answer to a bug report or click a reject PR button, then why should I put any effort?

Isn't it nice "git clone" was invented?

[palata]

> If you (plural) can't write a one line answer to a bug report or click a reject PR button, then why should I put any effort?

You wrote a PR because you benefited from source code that somebody on the internet shared for free, and wanted to share that work for free as well. See the PR as just one way to open source your patch. You could put it on your blog, in an email list, or keep it in a fork.

By opening a PR, you make it visible to other people who also benefit from the project and who may be interested in using it.

> then why should I put any effort?

Something I really want to say about this: if you decided to open a PR to an open source project, it is very likely that you put less effort into your PR than the other put into the open source project. But they gave it for free without complaining. You don't have to do it, but you can. And you will still have put less effort into it than the author.

[M95D]

> You could put it on your blog, in an email list, or keep it in a fork.

Get serious. Nobody's going to look into forks of a project to see what other people improved. Not even github has a search that good that would show bug fixes and improvements from forks that someone is searching for. How would you even search? (Well, to be honest, maybe Github has, or maybe Copilot can do that kind of search based on a half a page text description of what I'm looking for, but I'm really not aware that it exists.)

> By opening a PR, you make it visible to other people who also benefit from the project and who may be interested in using it.

Yeah, but if I have moral standards and care about not wasting those interested people's time, then I have to keep the PR forever maintained and rebased on current HEAD, even if I don't need to update my fork that often, or I stopped using that project altogether. If I didn't do that, then I would be a hypocrite.

[palata]

> Get serious. Nobody's going to look into forks

At this point you just sound like you want to complain. I was saying that opening a PR is a nice way to share a patch, and all you get from it is an opportunity to complain about how difficult it may be to find a patch in a fork.

> Yeah, but if I have moral standards and care about not wasting those interested people's time

This has nothing to do with moral standards. I have benefitted multiple times from old, unmerged, outdated PRs. Because if someone fixes a bug, the valuable part is understanding what is going wrong and how to fix it. An outdated PR saves me that time.

> If I didn't do that, then I would be a hypocrite.

Not at all. You just have a very weird way to look at it.

[Capricorn2481]

Just sounds like you've moved the goal posts to something completely different. This entire statement is addressing people frustrated with their half broken PRs being closed. It has nothing to do with "not clicking the reject button"

[M95D]

No I didn't. I said the same thing from my first comment: Ignoring PRs with no review, accept, or reject is wrong.