On Oct 31, 2008, at 12:43 PM, Stefan Walk wrote:
There are cases where one user replied to
multiple mails in a short time without fighting, just explaining and
discussiong, and you don't want to block that - as well as it
wouldn't stop
random people from suggesting dropping the $ from variables, making
the
namespace separator configurable etc. IMO, it's the volume of
people, not the
volume of messages, that is the main problem here.
As a semi-non-random person (though people who have become very
active only in the last few years may not remember me at all), I'd
like to put in my two cents, based on, oh, 8+ years of working with
this list, and my 22+ years of dealing with various lists/groups
(email goes back to 1961, FWIW, before I was born).
1. Having a fairly advanced MUA helps. If you don't know what an MUA
(Mail User Agent) is, then you may not remember the days when it was
easy to get 1,800-10,000 messages a day off of various lists. The way
this "message overload" problem was typically solved was with message
grouping, and mail rules. Don't want to read a thread? Delete whole
threads, not messages. Don't think a user is contributing? Put them
in the bit-bucket.
2. Random off-topic-ness happens. It cannot be dictated away,
moderated away, or programmed away. Feel free to try, but some of the
best minds in the world have worked on this issue for 47 (yes, 47)
years. No silver bullets, I'm afraid.
3. The "super-seekrit serious chat only about X" lists (or CC:
chains, or IRC meetings, or wiki pages, or whatever) already exist,
and have always existed. If people knew about them, they wouldn't be
"seekrit", and away from the riff-raff of a publicly available
mailing list. Most F/OSS projects have these back channels. They are
not made available for public use because, well, they're not supposed
to be.
4. If you are a developer of sufficient merit/need/value, you will
likely be on both public lists for a project, and have access to the
private back-channels for some things as well. This is just the way
the system works. Sure, we could make official rules, and another
shibboleth list/channel/chat/wiki, for a given piece of a project,
and add another layer... but to what end? We already have a plethora
of such channels, indeed, as a project grows, said channels create
themselves out of necessity.
So, to summarize, here's an example chain:
-php-general
-php-dev
-<redacted>, PHP sub-project "hidden/CC lists and chats"
-<redacted>, PHP core current C contributors and debuggers
-<NA> Zeev (or who ever's) cell phone
These layers already exist.
The problem is not that we (as a community) lack these levels of
discussion, the problem is that every so often, folks want to
escalate to another level, or find that they've outgrown the level
they're in, and complain about the 'Riff-Raff". If you contribute to
higher levels, if you work on a feature that impacts others at a
higher level, and want to also be a part of that smaller community,
well..... it already exists. It just doesn't always have a mailing
list that *anybody* can join because they "think they're important".
-Bop
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
