On 2013-01-16 7:20 PM, "Chad" <innocentkil...@gmail.com> wrote: > > On Wed, Jan 16, 2013 at 6:07 PM, Tim Starling <tstarl...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
