I think I have a few good reasons for this:
One: The line between cocoon users and developers is fairly thin, it is not as in Open Office for example, where most users do not even know what the C language is. Our users are more and more competent software developers who would often have interesting things to say if they were around, and might like this place more if they felt more involved. Cocoon has been finding its niche as a tool for serious application developers, as opposed to a press-button publishing tool, which it has never been and will never be.
Two: my guess is that many dev@ subscribers could answer some users@ questions very quickly, but sometimes we don't bother looking at the list, and some of us are probably not even subscribed there. It's a waste of energy, and has probably caused otherwise competent people to go away after not getting good enough answers.
Three: dev@ subscribers tend to use good messages subjects and [TOPIC MARKERS] in subject lines to make the lists easy to filter, visually or automatically. So I'm not worried about the increased traffic, we'll find a way to make it sortable by teaching our community about good subject lines or defining a few more [markers]. Okay, this is not really a *reason*, but it's needed for my argumentation ;-D
Four: for many subjects one does not know on which list to post, again a waste of energy as threads regulary bounce between the lists. We developers tend to discuss between ourselves things that are of general interest, without bothering to move to users@ as it's not "our home".
Five: having two lists, one for Highly Qualified Meritocratic Core Developers and another for Mere Users does not sound like the openness and flat structure that we're advocating (I'm being a bit provocative here, on purpose ;-)
Six; the closing down of the docs@ list has only been positive, by defragmenting the community w.r.t docs and allowing all developers to be informed of what's happening with the [docs] (hint: note the good use of the [marker]).
Seven: Having a single point of discussion will help us know our users better, this alone is worth its weight in bytes.
So, WDYT? -Bertrand
smime.p7s
Description: S/MIME cryptographic signature
