[Zope-dev] mailing list 'noise'

[Rik Hoekstra]

 >>
> >> > > > I dont see this as a problem: You only create a new list when the
> >> > > > traffic for that proposal gets too great for zope-dev. Threading
is
> >> > > > good enough before that point.
> >> > >
> >> > > Yes, but zope-dev has a relatively high traffic load... Why should
you
> >> > > have to put up with all that 'noise' if you're only interested in
posts
> >> > > for your comparatively small discussion?
>
> >> I read the
> >> 2-10 articles that I'm probably interested in, and miss the 95% which
> >> is almost always noise.
> >
> >The question is why you'd want to receive all this if you don't have to
> >(as remarked above).
>
> ...because it is usually a mistake to categorize any discussion as
> small, to exclude it from the mainstream zope-dev. I started this
> thread with a request that developers use zope-dev in the way
> requested by the Fishbowl Process document - but (I assume) it has
> also been valuable to people thinking about a next-generation wiki.
>
> That would not have happened if discussion was partitioned into Wikis
> (Todays wikis - not VaporWikiNG) unless some WikiNgWiki person was (by
> coincidence) keeping up with the FishbowlWiki.
>
> Are you really advocating that?

No, did I sound like I did?

>
> >as long as you can follow it. But for prolonged and diverging
> >discussions? Not quite IMO/Experience.
>
> Can you explain why?


Because discussion change topics.  Because most people only answer parts of
the post.
Because you throw away parts of the posts (I know you shouldn't but the mail
client is not under your control).
Because you loose overview and you can't step back and take a look at the
whole thread.. Because no one ever summarizes the discussions. They could,
but they won't.
I have done these kind of summaries for several intricate Zope related
discussions and when you start summarizing it gets very clear that for a
larger discussion only parts of the issues involved ever get discussed.
Or, to summarize my point, maillist discussion are hardly ever consolidated.
It's like having a meeting without an agenda or a chairman who gets the
thing going. In the case of a meething once in a while a good
chairman/moderator takes back the discussion, summarizes and puts up the
open points for further discussion. If you ever experience a meeting that
needed someone to guide it, but didn't have one, then you probably know what
I mean.


>
> >Or for discussions that you fall
> >into in the middle?
>
> Agreed - Todays Wikis are better than todays email list archives.

Ha! ;-)

>
> >And what if you want to follow discussions at
> >different places, with different tools and you depend on a POP Server or
> >differential access (POP/IMAP/Web) to a mailserver?
>
> Its true that the web model is increasingly becoming a lowest common
> denominator. Are your suggesting that a majority of Zope developers
> actually need that?

Um, I couldn't tell with any certainty. In light of the adoption of Wikis, I
suppose so yes. People seem to have been unsattisfied by the maillist and or
other discussion tools. It's also remarkable that DC did not adopt Squishdot
as a discussion forum, yes.

And apart from this, a WikiNG would benefit a much larger community, of
which I _am_ sure that it needs it.

>
> (Agreed, a VaporWikiNG that does both would be nice)

Agreed that for now there are no tools that do such thing. That is also why
it's worthwile to get WikiNG out of the vapor notwithstanding the myriad of
discussion tools that have been around for many years already.

>
> >As I understood it, the discussion is less about tools and more about
> >modes of discussion.
>
> But we couldnt be having this discussion (in any mode) without tools.
>

did I say that?

> *My* email and news tools support the mode of discussion that we are
> advocating *better* than *Todays* Wikis
>

I think everyone agees about that, but at least some of the participants in
this discussion also agree that most of the existing discussion tools for
any mode of discussion are frustrating and insufficient at times. Moreover,
apparently not everyone favours the same mode of discussion and this alone
would be more than enough justification for a product that would cater
different modes of discussion _at_the_same_time_.

Rik