I understand that if I'm fully learned up on git, AND I know the solution to
the issue found, it's probably very simple to make a patch. The thing is,
I'm not skilled in git yet, and yes, I know this is an opportunity to
learn. Right now I don't have time.
If you need any kind of help in making the patch, you can always hit
me up in #rails-contrib. I'm usually always around.
By removing my issue you're saying
that if I'm unable to make the patch, you don't want to hear about the
Not really. If you're looking to have a disucssion when you're not
100% sure about something, or want your opinions to be heard by a much
larger crowd, you should always try mailing list first.
I guess my point is that if you're choosing not to accept issues where the
documentation is inconsistent with how the framework works, and you're not
accepting issues where the documentation is wrong, then you're losing an
opportunity to improve the framework/docs when the people finding these
issues aren't in a position to make a patch.
I personally think ( from what I've seen so far ), no one will ever
notice a ticket like that. And it'll go unnoticed for months hidden at
the very bottom of the pile of open tickets.
If someone finds an issues and
logs it, then they my be back to fix it when they have time. But, I haven't
really followed Rails core, and maybe that just doesn't happen here.
It depends on the severity of the issue. For very corner cases, yeah,
it rarely happens. No one usually comes back to fix them, till
someone, who has time, cares enough to submit a patch.
It comes down to "IMO removing valid issues just because they involve docs is a bad idea". Moving on..
Closing the ticket doesn't remove them. They'll still show up in search results.