[dmethvin]

This is from a year ago.

As someone who wants to contribute to a project for the first time, there would be nothing more frustrating than spending time creating what I think is a good pull request, only to have it be turned down (which it will be).

Issues help new contributors and repo veterans determine whether it's worth the extra effort to create a pull request. The problem with low-quality issues needs to be addressed by automation and filters, which GitHub hasn't done yet.

[ReligiousFlames]

How can we mentor the next gen of code craftsmen/women if we disengage and unplug the phone?

[bowlich]

Fork it, fix it. Pull in upstream changes until the maintainer fixes it. I suppose file a ticket with a snippet of what I did to fix it so a regular contributor can create a request faster.

If this is a random one-off drive by bug, then why go through the hassle of figuring out what particular standards any individual maintainer wants to follow just to have it turned down, or discover that some regular contributor already patched it while I reading the documentation.

(I mean, I'd love to contribute, but the few times that I've stumbled upon a bug, fixed it, figured everything the maintainer wanted in a pull request... it was aleady fixed by the maintainer and I'd just wasted a lot of time)

[chii]

> Pull in upstream changes until the maintainer fixes it

that's not a very scalable thing to do, as it involves unbounded amount of work. what if the maintainer never pull in your fix?