Martijn Faassen wrote:
> What lowered the quality of this discussion? I think it is because
> various people became quite upset and annoyed. That's because I reverted
> Hanno's changes to the ZTK trunk. I shouldn't have done that just like
> that, but I needed the subsequent discussion to come up with a better
I think you and Hanno were probably both equally wrong. :-)
- Hanno's work probably should've been in a branch with a post here
asking to merge it
- You probably shouldn't have reverted his work so quickly. Few things
irk developers like having their work (or others' work they care about)
> In the turmoil, my attempts to formulate a solution that would satisfy
> everybody's concerns fairly well seemed to have been overlooked a little
> bit. Instead we focused a lot of time on discussing bits we ironically
> enough actually more or less agreed about, such as the role of the ZTK.
> Nobody seemed to quite notice that I'm in fact in favor of a smaller
> ZTK, even though I said so repeatedly.
> That's because I'm *also* in favor of maintaining the zopeapp bits a
> while longer and not just throwing those away. I want an exit strategy
> for those bits. A transition strategy. That is a legitimate topic for
> this mailing list at the very least.
> Instead, we had endless debates about whether it was a legitimate
> concern for the ZTK maintainers. I'm of course still right that it is.
> I have wonderful and coherent reasons to support my position just like
> everybody else does who disagrees with me. It's not really very
> important anyway. We're here together on this list to work together
> beyond the ZTK itself.
I think one problem is that we speak about abstract groups of people,
"the ZTK maintainers", or "the Zope 3 maintainers" and now "The ZopeApp
maintainers". These groups don't really exist in any cultural sense.
They don't have an identity in the same way that, say, the Plone
maintainers or the Grok maintainers (and possibly, the Zope 2
maintainers) do. It's hard for any one group to make their voice heard
when no-one knows if they're part of that group or not. :)
I think in general, it's more useful to talk about "the Zope community"
until such time that these groups actually self-organise, if indeed they
> So how can we have better discussions?
> We can have better discussions by helping me.
> How can you help me? Of course it helps if you agree with me. I realize
> that's frequently infeasible, but I certainly wouldn't mind. :)
> If you disagree with me, I'd like you to try to understand my concerns
> as much as you possibly can. In addition, try acknowledge my concerns as
> much as you possibly can without feeling you're lying. This works beter
> than just rejecting them.
I think this goes for anyone, not just for you.
> How else can you help me?
> You can propose realistic solutions for how we as a community can take
> care of these concerns that I have. And still fulfill your concerns at
> the same time. Such solutions were entirely possible in this discussion.
> Constructive debating is an art I'm still learning, but I had the
> feeling people enjoyed the rest of the debate too much to be very
> constructive this time...
> Of course the way you'd help me is the way anybody would be helped in a
> discussion, as the discussion becomes more constructive.
> Again, I know as much to blame as anyone else. I helped spark it due to
> my revert and my continued insistence that I am right. The revert
> shouldn't have happened. But I didn't know that at the time as I hadn't
> had time to think yet either.
I think there's another lesson here: reverts are the open source
equivalent of swearing at someone. It may seem like a good idea at the
time, but it is basically saying "your work is not wanted here". It
offends at an emotional level and means the discussion easily stops
being factual. It's a lot better to ask the developer to do the revert
himself, if needed. At least then he has a chance to make the point.
> So how else can you help me? Give me some space to think. I believe my
> concerns could have been easily taken care of if we'd stopped and talked
> for a little bit *before* drastic changes were checked in. So, you can
> help me by discussing things that you know are drastic changes before
> you do them.
I think we normally have a policy of making invasive changes on a branch
and then posting here with a "proposal" to merge it. That's not a bad
thing. We need to acknowledge that most of the work that happens in Zope
land these days is about building a shared infrastructure for a few more
user-facing projects: Grok, BFG, Zope 2, Plone, and possibly "full-stack
Zope 3". That means that there are a lot of stakeholders who have quite
a big stake in some of our changes. We can't just unilaterally make changes.
On the other hand, I think we almost always agree on what needs to be
done, and I think we almost always come to constructive and useful
conclusions. It can just take som etime.
> I know we have had a lot of problems reaching conclusions in such
> discussions in the past, but we can't learn how to do better at that if
> we don't. And we are going to do better if I can help it.
I think we normally do reach conclusions, thanks often to people like
you tirelessly summarising and soliciting input. I don't think that part
is broken. Big discussion threads usually mean people are either
passionate about or highly dependent on Zope as a framework, or both.
I'd take that over apathy any day.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -