[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: Gavin Baumanis <gavinb_at_thespidernet.com>
Date: Wed, 1 Apr 2009 21:56:00 +1100

+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=1505814
Received on 2009-04-01 12:57:22 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.