On Fri, Oct 31, 2008 at 20:30, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > A simpler approach might be to just make the mailing list software enforce a > 1 email per 24-hour day per user. It would require a bit more upfront work
Thats not going to work, we often have multiple threads going on. Even if it was limited to one post per thread every 24hour people would simply create new threads about the same topic. Restricting the amount of mail is no solution, just causes annoyances. > to munge the software, but wouldn't require any ongoing effort. Moderation > can get messy since it isn't simply spam we or off-topic messages we are > trying to control here, it is the volume, quality and timeliness of on-topic > messages. I'm not sure moderation is the answer to that. We need a > behavioural change here. Behavioural change is desperately needed, and I think developers should lead by example. One way to to that is to add a new internal-core@ mailinglist which is read-only to the world, and writeable by people with appropriate karma. That list would be dedicated for _development_ discussion (including implementation, patches, "edge-case voting" and such things) and would include posts like are going on between greg, stas and dmitry, and posts which are going on between release managers and individual developers. This way we keep _everything_ in the open and maintain a "high quality" on-topic discussions. "external" patches and "general" discussions would still be on the internals@ list, as it would be the main discussion list. However, those who simply do not have the time to read over the entire thing have a specific low-traffic list which they can easily follow. For people not with "write privileges" they can still chime in by forwarding the posts to internals@ and give their 2cents. Another indirect advantage is when docwriters mail in asking what exactly something does, and if it really is meant to work that way, the thread is obviously coming from "internal" guy and therefore has a better chance of getting answers (rather then the "usual" ignore since apparently think he is just a troll). I cannot see any disadvantages here. I have faith in our developers. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
