Steve asked me to give a little feedback on the contributing guide based on a conversation we had on twitter wherein I mentioned that the process of shepherding a pull request to completion was opaque to me.
I like to think that I have a fair idea of how to contribute to open source generally, but haven't had much luck with Rails specifically. There's actually a running joke at work that while I might put work into a new feature or to fixing a bug, it'll never get merged so it doesn't matter.
Normally I'd try to make improvements here myself, but 1. I don't seem to "get" contributing here and 2. as I said, it probably wouldn't get merged :D.
Here goes:
-
Sanity Check
You know at least one other Rails developer, right?
I do, as I have the luxury of having several coworkers with deep ties to the Rails codebase as well as several more who have contributed. However, I doubt that most people who would be here would, and this comes off as pretentious.
http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#sanity-check
-
Get some Feedback
You can use the rubyonrails-core mailing list or the #rails-contrib channel on IRC freenode for this.
Both of these suggestions feel tautological. The people who would subscribe to the mailing list or spend time in the IRC rooms are the same people who are "notified about your submission", right? Why am I telling them again? They already know, I'm sure.
Those are the thoughts that go through my head when reading this, at least.
http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#get-some-feedback
-
Features versus Bugfixes
I still see this change (rails/rails#11873) as a bugfix, as it is unexpected behavior using an established feature. It took me a few hours to figure out why it didn't work, so there should have at least been a descriptive error message in this case.
However, several people (rails/rails#11874) seemed to feel that it was a feature.
Having a documented definition of where that line is drawn would be useful.
<3