I'm a huge fan of drive-by commits. GitHub's web editor makes it really easy to correct a typo or add a two-line fix - and for many people that might be their first contribution to open-source, without the faff of downloading git etc.
Maybe for documentation or source-comment fixes, but most code fixes should have one or more unit tests to accompany them. To me, a pull request represents something that should be pretty close to finished work. There may be a few style issues to clean up but it should be functionally done.
If someone wants to discuss how to approach or solve a problem in general without working and tested code, I'd prefer to see that happen in the bug/issue rather than a pull request. Otherwise it can lead to wasted effort and/or hurt feelings on the part of the contributor.
8 comments
[ 3.1 ms ] story [ 41.6 ms ] threadand link to the paper concerned: http://se.uni-hannover.de/pub/File/pdfpapers/Pham2012.pdf
If someone wants to discuss how to approach or solve a problem in general without working and tested code, I'd prefer to see that happen in the bug/issue rather than a pull request. Otherwise it can lead to wasted effort and/or hurt feelings on the part of the contributor.