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.
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
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2009-03-31 18:00:29 CEST