6 ms·

I know it's not best practice, but I leave them open. For years. They may be fixable, they may be useful to someone. I've no need to reject them unless I reall

I know it's not best practice, but I leave them open. For years. They may be fixable, they may be useful to someone. I've no need to reject them unless I really think they're a bad idea. I'm sure this can be frustrating to users and contributors, but I also see it as a way of encouraging forks. "I haven't had a chance to review this, but you might try PR #NN..." The most useful ones get replaced by better versions by other people, and eventually merged.

flurdy 10y ago
That depends on if you respond with a comment that indicates it's not likely to be merged. Then it is understandable, otherwise it is just rude and confusing.
- fourthark 10y ago
  Well, I usually say that it needs tests, and in my crowd that's equivalent. :-/
unixhero 10y ago
Yeah. But it is not the way PR and Git is intended
- palunon 10y ago
  Git is intended to work over email. How do you close an email PR ?
  - pm215 10y ago
    You reply to the email saying 'sorry, but we can't accept your code because...'. (The shortest way to do this is to just reply saying 'NAK', but I agree with Rusty Russell that nak-mails are generally unfriendly and a bad idea: http://ozlabs.org/~rusty/index.cgi/tech/2007-05-04.html http://ozlabs.org/~rusty/index.cgi/tech/2007-05-04.html)
sfifs 10y ago
this strategy is ok as long as you explicitly indicate in the issue you might not get around to reviewing soon but to go ahead and fork. I've seen too many folks who just leave PRs hanging which leads to frustration. People will remember and think twice about contributing to anything with your name/id in it.
- maweki 10y ago
  I have some PRs hanging around that are just translation fixes. How the heck can a maintainer not merge some translation fixes? For years... About every quarter I write something like "is there something wrong with this PR?" "can I do something else to get this merged". Usually without reaction.
- scaryclam 10y ago
  I'm actually quite bad for this. I think this year I might make it a new years resolution to retroactively apologise and add comments about forking, and try to make sure any future PRs get an answer one way or another.

flurdy 10y ago

That depends on if you respond with a comment that indicates it's not likely to be merged. Then it is understandable, otherwise it is just rude and confusing.

fourthark 10y ago
Well, I usually say that it needs tests, and in my crowd that's equivalent. :-/

unixhero 10y ago

Yeah. But it is not the way PR and Git is intended

palunon 10y ago
Git is intended to work over email. How do you close an email PR ?
- pm215 10y ago
  You reply to the email saying 'sorry, but we can't accept your code because...'. (The shortest way to do this is to just reply saying 'NAK', but I agree with Rusty Russell that nak-mails are generally unfriendly and a bad idea: http://ozlabs.org/~rusty/index.cgi/tech/2007-05-04.html http://ozlabs.org/~rusty/index.cgi/tech/2007-05-04.html)

sfifs 10y ago

this strategy is ok as long as you explicitly indicate in the issue you might not get around to reviewing soon but to go ahead and fork. I've seen too many folks who just leave PRs hanging which leads to frustration. People will remember and think twice about contributing to anything with your name/id in it.

maweki 10y ago
I have some PRs hanging around that are just translation fixes. How the heck can a maintainer not merge some translation fixes? For years... About every quarter I write something like "is there something wrong with this PR?" "can I do something else to get this merged". Usually without reaction.
scaryclam 10y ago
I'm actually quite bad for this. I think this year I might make it a new years resolution to retroactively apologise and add comments about forking, and try to make sure any future PRs get an answer one way or another.