RE: Proposal for an emacs-humanities mailing list

[Drew Adams]

> > Chiming in here, but not with a strong opinion...
> [...]
> > An alternative might be to start by inviting potential
> > "humanities" participants to use help-gnu-emacs (or
> > emacs-tangents?), but with a particular prefix in the
> > Subject line.  If volume becomes reasonably high then
> > a new mailing list could be spun off to handle it (but
> > with the attendant lack of visibility to some that I
> > mentioned above).
> 
> At first blush a good idea. After giving it a second
> thought, I think one of the strong points of a separate
> list might be that non-hackers (by which I mean those
> that consider themselves to be non-hackers!) might feel
> intimidated by volume, style or content (or all three!)
> of help-gnu-emacs.

Yes, that is a potential downside, for such users.
OTOH, they may get more eyeballs from people who
may be able to help with some of the Emacs(-Lisp)
side of things.

The idea is to grow things incrementally.  The
more such users there are, the more who are
inconvenienced in the way you suggest, and the
more impetus to spin off a separate list.  

In a nutshell: try inviting "humanities" (or any
other category of) users with a simple approach,
and see how it goes.  Deal with it accordingly
after everyone has seen what the real need/want is.

> I concur that the cost of setting up a new mailing list
> is minimal.

That's not really the question, to me at least.

> Perhaps... to reassure those fearing lots of "empty"
> lists,

To be clear, I don't fear empty lists.  That isn't
why I made the suggestion to start by labeling mail
in an existing list.

> perhaps it should be wise to sketch some kind
> of "teardown procedure": six months after set up, if
> less than N mails per time unit have been seen, a
> teardown message is sent. If nobody complains, the
> list is shut down. Or something.

I'd suggest that no such predefined rule be set up,
and that people just play it by ear.  IOW, see how it
goes and adapt accordingly.  IOW, have a discussion
about how best to handle whatever traffic develops
once we can see what that traffic might really look like.

> But then perhaps this is just one more sticky bit of
> red tape.

Develop red tape as needed, not before then.  Lazy
evaluation.