REMINDER: Keep technical discussions on zope-dev!
I'm resending the message below as a gentle nudge for folks. There are some more email threads such as: o Exception ThreadLock.error: 'release unlocked lock' o Using regexes in DTML expressions o Property Sheet Questions o How can you tell if what kind of object it is? ...that are better discussed on zope-dev@zope.org. I'm not trying to be _too_ much of a nag, but I'm getting a LOT of feedback from people again saying the traffic is overwhelming and the list needs to be split. ---------- Just a quick reminder: there is another mailing list (zope-dev@zope.org) for technical questions. A quick glance through the last 50 or so zope@zope.org messages shows that over half of them are more appropriate for "developers" than "content managers" or a general audience. zope-dev was created namely because the community wanted to better manage the volume (read: deluge) of Zope mail. After a long discussion which generated many emails :^), the community agreed to having a list for general and introductory questions and a list focused on developers. Some example email discussion threads that could be moved over: o ZClass constructor / namespace question o Comma delimited file and the re python object o complex question (kind of an obvious one :^) o Random ID's using ZopeDate() problems... o xmlrpc calls require string results? Ken wrote a script that shows the subscription/unsubscription rate on the mailing lists. Around the time of the split we saw the ratio improve, meaning fewer people were getting frustrated. The ratio has gotten worse again. Let's work to make sure the traffic gets managed as best as possible. Thanks! --Paul Paul Everitt Digital Creations paul@digicool.com 540.371.6909 ----------------------------------------- The Open Source Zope application server http://www.zope.org/
On 10 Nov, Paul Everitt wrote:
I'm resending the message below as a gentle nudge for folks. There are some more email threads such as:
o Exception ThreadLock.error: 'release unlocked lock'
o Using regexes in DTML expressions
o Property Sheet Questions
o How can you tell if what kind of object it is?
...that are better discussed on zope-dev@zope.org.
What we have here is a failure to communicate. When I see a choice between two lists, zope and zope-dev, I assume the first is for the users of Zope -- all the people using all the facilities Zope provides to build, publish and maintain web sites. I assume the second is for the developers of Zope -- all the people working on the code which makes up Zope, fixing bugs, adding features, preparing the release of Zope 2.1. Given that understanding, only the first of your four examples strikes me as a topic which might belong on zope-dev. All the others relate to topics about how to use Zope. You are asking those on the zope list to move to the zope-dev list when they have a topic which is "technical". That is a judgment call which no two readers will make the same. Where should questions about aquisition be posted? That's a pretty complex topic which confuses most people at least at first. Is that "technical"? On the other hand, it's a topic which every Zope user who builds anything beyond the most trivial web site needs to understand. If topics are sorted based on the vague notion of "technical", I have no idea which list will have the answers to questions I have. Consequently, I'll have to subscribe to both lists. So much for managing the traffic problem.
I'm not trying to be _too_ much of a nag, but I'm getting a LOT of feedback from people again saying the traffic is overwhelming and the list needs to be split.
The traffic *is* overwhelming, and the list does need to be split, but split it into clear subtopics (DTML, Databases, ZClasses, ...). Also, retain the zope list as one which distributes all the messages. That is, every message to a sub-list is copied to the main zope list. That way zope remains the list for people who are interested in all aspect of using Zope, say, because they're a one-man shop. People interested in more focused discussions could subscribe only to, say, zope-db. I'm enough of a Zope newbie, I won't venture to enumerate a list of subtopics, but any partition will be better than some vague advice that "technical" messages belong on zope-dev. BTW, if zope-dev is not for the developers of zope, then what mailing list is for them? Surely an open-source project has a mailing list on which its developers discuss design issues? -- | Don Porter dgporter@erols.com | | "Some days you just can't get rid of a bomb!" | | -- Adam West as BATMAN | |______________________________________________________________________|
On Wed, 10 Nov 1999, Don Porter wrote:
When I see a choice between two lists, zope and zope-dev, I assume the first is for the users of Zope -- all the people using all the facilities Zope provides to build, publish and maintain web sites. I assume the second is for the developers of Zope -- all the people working on the code which makes up Zope, fixing bugs, adding features, preparing the release of Zope 2.1.
That is how I think aboy these lists.
Also, retain the zope list as one which distributes all the messages. That is, every message to a sub-list is copied to the main zope list. That way zope remains the list for people who are interested in all aspect of using Zope, say, because they're a one-man shop. People interested in more focused discussions could subscribe only to, say, zope-db.
Exactly! In any case I subscribed to all (now 3) lists. Making special list gatewaying all other lists will bi nice! Oleg. ---- Oleg Broytmann Foundation for Effective Policies phd@phd.russ.ru Programmers don't die, they just GOSUB without RETURN.
I have to agree with Don, here. The criteria that 'technical' discussions should go to zope-dev is a bit to vague to be meaningful. Even the distinction between Zope 'users' and 'developers' is a difficult one, as every Zope user is a 'developer' in some sense, even if they're writing only the most trivial DTML method. Also, very often a question about general usability evolves into a discussion about the internal workings of Zope. In these cases, someone must make the effort to move the thread over to the zope-dev list, at the risk of losing some of the audience that may be able to help them solve their problem. Examples:
o Exception ThreadLock.error: 'release unlocked lock'
This started as a general usability / configuration issue, as the site administrator was seeing this exception during the normal use of their Zope server.
o Using regexes in DTML expressions
This started as a basic DTML 'how-to' question.
o Property Sheet Questions
A little more 'technical', as ZClasses were involved, but mainly just basic DTML questions. Do all questions involving ZClasses belong on zope-dev?
o How can you tell if what kind of object it is?
Again, a basic DTML 'how-to' question. Paul, What do you think about Don's suggestion to break out the zope list into several clearly defined sub-topics (DTML, ZClasses, databases) instead of trying to distinguish between 'technical' vs. 'non-technical' questions? Unfortunately, I can see this being as difficult to judge. ("Is this a DTML question or a ZSQL question?") I'm mainly just interested in generating some discussion about possible solutions. -jfarr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hi! I'm a signature virus. Copy me into your .sig to join the fun! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hello
On 10 Nov, Paul Everitt wrote: [snip]
And At 11:06 10/11/99 -0500, Don Porter replied:
What we have here is a failure to communicate.
When I see a choice between two lists, zope and zope-dev, I assume ...[snip great post]
Yes thank you! zope-dev is a very confusing name. zope-dev implies 2 possible meaning to me: a.- developers OF zope ie = people changing the source, asking bug questions, ideas for clarifying syntax etc.. developers of the tool itself or b.- developers working WITH zope ie = people who are using zope to develop zope-based applications Don Porter proposes an excellent idea: break down the list with duplicates copied off by content DTML, Databases, ZClasses, ExternalMethods, etc. The list is overwhelming and like many i spend a substantial part of my morning going through messages, saving snippets in my Zope scrapbook, compiling printouts. Even the best message header becomes unwieldy when there is a hot thread. I am not complaining about the volume - this vibrant community is one of the _best_ things about zope. But How best to manage it? It occurs to me that by nature if its design , Zope deserves a smarter more configurable way to handle its own growing mailing lists. Wouldn't it be great if zope.org had a manager_mailsub interface to the mail list subscription routing? or perhaps a way to embed short DTML in the subject header or first line which would allow the mail list method_engine to parse. Would be a worthwhile experiment I think. For those who abhor complexity or don't want to risk missing something, a single zope-all@zope.org list could bundle everything. - Jason ------------------------------------------------- Jason Cunliffe <jasonic@nomadicsltd.com> NOMADICS.STUDIO(Design Director) Geo-Digital Arts and Technology Le Vieux Moulin, Route de Mons 83440 SEILLANS, FRANCE Tel: +33 (0)4 94.76.98.72 Fax: +33 (0)4 94.76.97.77
participants (5)
-
Don Porter -
Jason Cunliffe -
Jonothan Farr -
Oleg Broytmann -
Paul Everitt