On 2013-01-16 7:20 PM, "Chad" innocentkiller@gmail.com wrote:
On Wed, Jan 16, 2013 at 6:07 PM, Tim Starling tstarling@wikimedia.org
wrote:
On 17/01/13 00:14, Chad wrote:
Really, I think the whole thread is moot with the pending upgrade. Typos should always be fixed before merging (I think we all agree?), and the new abilities to fix these from the UI means we won't need to mark people as -1 to do so.
I didn't mention commit summaries in my post. My interest is in nitpicking in general. Jeroen calls arguments over commit summaries the /ultimate/ bikeshed, which they may or may not be; there are plenty of other examples which may compete for that title.
Indeed, I had missed that.
Nitpicking is the minor end of the negative feedback spectrum. By definition, it has the smallest concrete payoff when advice is followed, in exchange for complex, context-dependent social costs. You should think carefully before you do it.
*nod* I agree. And really, nitpicks in code can always be cleaned up later (heck, we did it for years with SVN).
It's only nitpicks in commit messages that should always be fixed, since they're immutable after submission. And it's *that* that I think won't be a big deal anymore (since any drive-by contributor could fix a typo on the spot).
If we're talking nitpicks in general. Ive seen -1 for things like someFunc($a, $b) instead of someFunc( $a, $b ) which I agree does more harm than good.
I imagine how much someone considers spelling issues to be a minor "nitpick" varries quite a lot between people. -bawolff