emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for an emacs-humanities mailing list


From: Karl Fogel
Subject: Re: Proposal for an emacs-humanities mailing list
Date: Mon, 30 Nov 2020 15:27:41 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

On 30 Nov 2020, Eli Zaretskii wrote:
>On November 30, 2020 6:40:00 AM GMT+02:00, Karl Fogel <kfogel@red-bean.com> 
>wrote:
>> On 30 Nov 2020, Eli Zaretskii wrote:
>> >However, I don't understand what is expected from the active Emacs
>> >developers wrt this list.  It sounds like they will need to subscribe
>> >to this new list, for it to be useful?
>> 
>> I don't think we need to assume that.  Emacs's extensibility and
>> customizability mean that there are plenty of beneficial suggestions
>> that users can make to each other without getting active core
>> developers involved.  And when a topic does warrant the attention of a
>> maintainer, then someone from the new list can come find one (perhaps
>> by posting on Emacs Devel if appropriate).
>
>Do you really think this will work?  I don't, FWIW.  How can a group of
>people not involved with development answer non-trivial questions,
>suggest reporting useful bugs and feature requests etc.?

Yes, I think it could work.  To your second question, there are two 
non-mutually-exclusive answers:

First, plenty of free software (and even non-free software) applications have 
domain-specific users groups that don't involve a lot of participation from 
active maintainers.  It's normal for there to be expert users who, although 
they are not maintainers, still have collectively a large body of knowledge to 
share.  For example, on this proposed list, I would expect a lot of people who 
have expertise in using TeX / LaTeX modes in Emacs to answer questions -- and 
there is probably only slight correlation between having that expertise and 
being an Emacs maintainer.

Second, in the particular case of Emacs, the software's extensible architecture 
makes it especially probable that non-maintainer users would have deep 
expertise in certain areas.  There are so many specialized modes available, and 
so many domain-specific usage tips and configuration tricks, that whether a 
person is or is not an active *maintainer* of Emacs might not correlate very 
strongly with that person participating usefully in a discussion.  (Also, don't 
code contributions regularly come in from people who are not maintainers?)

>Even help-gnu-emacs would not be the same without several developers
>dwelling there.  Posting to emacs-devel is a slippery path to making
>this new list a branch of the existing ones, something that this
>initiative wants explicitly to avoid.  I'm probably missing something
>here.

The cost if the experiment fails is a dead list sitting on a server.  That cost 
doesn't seem very high to me in any case, and given the enthusiasm we've heard 
so far for it, I think the chances that the experiment would fail -- or at 
least that it would fail quickly -- are probably at worst 50%.

Remember, someone *from* the domain in question is coming to us and saying that 
there is interest (and others have corroborated).  If we say "yes" 10 times, 
and 9 of those times fail, and 1 time there is a new mailing list that turns 
out to be the right watering hole for a sub-community of users, well, that 
seems like a pretty good outcome to me.  (Unless the list creation/admin 
overhead is much higher than I would normally assume.)

I understood the 'emacs-tangents' list to be basically a default place to get 
certain discussions off of 'emacs-devel'.  But this proposed new list is 
different.  It's not defined by a negative space, it's defined by a positive 
space: a semi-cohesive group that is likely to have various usage needs in 
common, and whose needs may eventually make their way back to Emacs Devel in 
the form of beneficial suggestions for Emacs.  I could be wrong about this, of 
course; I'm just saying the chances look good enough that IMHO creating the 
list and seeing if it works is worth it.

Best regards,
-Karl



reply via email to

[Prev in Thread] Current Thread [Next in Thread]