Mario Mommer wrote:
How about just
regex-coach-{devel|announce|help}@common-lisp.netjust no project?
Ok, good point. Then I guess Brian's list would have to be mac-ui-devel. All ok with this? If so I'll go ahead and set up the two lists and create the extra webpage that enumerates all of these no-project lists.
Erik.
On Tue, 27 Jan 2004, Erik Enge wrote:
Mario Mommer wrote:
How about just
regex-coach-{devel|announce|help}@common-lisp.netjust no project?
Ok, good point. Then I guess Brian's list would have to be mac-ui-devel. All ok with this? If so I'll go ahead and set
I'm ok. Though I'd suggest that we offer the choise of postfix to the original requester. For some -talk, or -list may be preferable.
While on the topic: though I like the default of -devel, -help, and -announce, for most hosted projects this is actually a bit excessive: -devel would seem to be enough. As a result we host a huge number of stale lists, and while this is essentially "free" for us, it increases the likelyhood that someone interested in project foo will subscribe to a dead list and wonder where eveyone is...
Hence, I'd like to suggest that we from now on would by default generate only -devel list for new projects, unless they request more. Projects prior to 1.0 seldom need -help or -announce.
What do you think?
Cheers,
-- Nikodemus
Nikodemus Siivola tsiivola@cc.hut.fi writes:
While on the topic: though I like the default of -devel, -help, and -announce, for most hosted projects this is actually a bit excessive: -devel would seem to be enough. As a result we host a huge number of stale lists, and while this is essentially "free" for us, it increases the likelyhood that someone interested in project foo will subscribe to a dead list and wonder where eveyone is...
Hence, I'd like to suggest that we from now on would by default generate only -devel list for new projects, unless they request more. Projects prior to 1.0 seldom need -help or -announce.
What do you think?
I think that your idea is good. But IIRC, we've had this discussion before, and the conclusion was that since the current policy minimizes the amount of administration, it is better. I wonder if better tools could add flexibility to this and keep the administration overhead almost as low.
Regards, Mario.
-
Erik Enge -
Mario Mommer -
Nikodemus Siivola