[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Respect for fellow developers (was: svn commit: r36895 ...)

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 1 Apr 2009 14:09:20 +0200

Nice. And sure, it could be applied to the svn community.

The comment about "being simple"... that's how google's "do no evil"
motto came up. Some people were listing a whole bunch of "do's and
don'ts" on a whiteboard, and I think it was Paul Bucheit who said
something like "um. how about erasing all that just put down 'do no
evil'?".

Cheers,
-g

On Wed, Apr 1, 2009 at 12:56, Gavin 'Beau' Baumanis
<gavinb_at_thespidernet.com> wrote:
> +1
>
> Perhaps there's scope for this (advice) to be included in HACKING?
>
> Of course, nothing to do with THIS issue, but none the less I feel a worthy
> message for new community members and the experienced, alike.
>
> I remember back in the days of dial-up BBS's the posting rules contained
> this "gem";
>
> (paraphrasing)
> Do Not excessively annoy other.
> Do not allow yourself to be excessively annoyed.
>
> These two very simple rules seemed to keep nearly all "irritations" at an
> acceptable level.
>
> And while those two aren't necessarily applicable to the SVN community - I
> bring them to the lists' attention as an illustration of how something
> "simple" need only be, to be effective.
>
> Beau.
>
>
> On 01/04/2009, at 3:00 AM, C. Michael Pilato wrote:
>
>> Greg Stein wrote:
>>>
>>> I nearly expounded on this in the log message, but decided that a
>>> regular email to the list is a much better approach. Specifically to
>>> talk about respect for your fellow developers.
>>>
>>> When Jane vetoes John's change, then a discussion needs to be started
>>> about the change and what kind of resolution is warranted. Jane does
>>> NOT immediately revert John's change. He may be right after all, or
>>> maybe with some tweaks, the technical problem can be corrected. This
>>> is about showing respect to John to determine the final course of
>>> action. He will let his change stand (Jane removes her veto after some
>>> discussion), he can tweak it (some compromise is reached after
>>> discussion), or he can revert it when he realizes that his fellow
>>> developers disagree with his change and no compromise solution looks
>>> to be available. Jane gives hoim the respect, the time, and the
>>> discussion to take the appropriate course of action.
>>>
>>> However, when that third option is reached: the veto stands, even
>>> after discussion, then John MUST respect that decision. This is a
>>> community of peers, and we need to show respect to the opinions,
>>> decisions, and approaches of others. That also means vetoes should not
>>> be casually thrown around: it is a very harsh measure of your peer's
>>> work. In many cases, you may want to consider whether John's change is
>>> "good enough" and just let it stand. Or provide some review on how it
>>> could be improved. Pulling out the veto card is divisive, so Jane
>>> needs to really think about whether the technical problems introduced
>>> by the change warrant her veto.
>>>
>>> And with that said, I didn't see the two vetoed revisions getting
>>> backed out as they should have. I wanted to let the original developer
>>> do it, but he was not respecting mine and Branko's issues on the
>>> matter. So with reluctance, I had to do it myself.
>>>
>>> Then write this email for why I feel that was wrong.
>>>
>>> -g
>>
>> Greg, this is a good reminder to all about the kind of fundamental, mutual
>> respect that makes this community function at all.
>>
>> I would further admonish folks to be aware of the danger of ignoring the
>> small fissures that can form in relationships -- especially remote ones
>> such
>> as we mostly have represented in our community -- and to proactively work
>> to
>> repair those matters privately before deeper damage is done.  (And to do
>> so
>> using whatever medium is required for clear communication).  Life is far
>> too
>> short, and our individual pride far too valueless, to permit discord
>> amongst
>> each other.
>>
>> --
>> C. Michael Pilato <cmpilato_at_collab.net>
>> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>>
>> ------------------------------------------------------
>>
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1497158
>
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1506376
Received on 2009-04-01 14:09:38 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.