Mailing list guidelines? (was: Bind right shift and TAB won't work)

[Bob Proulx]

Drew Adams wrote:
> Emanuel Berg wrote:
> > > Emacs has a FAQ: http://www.gnu.org/software/emacs/emacs-faq.html
> > 
> > Yes, but I was wondering more if there were any guidelines how to
> > interact in this very group. Like how much context to provide, and
> > stuff like that. If you use some special notation to highlight
> > commands. Etc.
> 
> Dunno.  I probably should know, but I don't.  I looked here, but it
> doesn't lead to any such guidelines, AFAICT: http://lists.gnu.org/.
> ...
> Perhaps someone else can point you to some guidelines for the list
> somewhere.

This is a much more complex issue than it should be at first glance.
It is hard to talk about it without a long discussion with details.

The GNU mailing lists don't have a written down code of conduct the
same that that some other free(dom) software organizations do.  For
example Debian has had a long standing Code of Conduct.  I have always
found that written down policies are best because then everyone can be
working from the same set of rules.

  http://www.debian.org/MailingLists/#codeofconduct

Unfortunately the GNU mailing lists have no such written down code of
conduct.  GNU is in many ways less of a single project as a collection
of individual projects.  Each maintainer or maintainer team is given
wide leeway to run their project and the associated mailing lists as
they see fit.  This often makes it seem more like a collection of
greek city-states rather than a single nation.  Every project has
their own rules.

> This is a help list, so pretty much anything you write will be OK.

Yes.  However I like the last rule above the best.  "Use common sense
all the time."  :-)  That is as nebulous and vague of a rule as you
will ever find but it is the best guideline just the same. :-)

> The preference is for plain text, not HTML mail.  Other than that,
> trying to provide clear & complete info in your questions is
> helpful, as is referring to specific doc sections or specific
> recipes to reproduce behavior, when appropriate.

Yes.  Also I will note that lately people have been sending very large
messages through the mailing list.  Not on help-emacs but on some of
the other mailing lists.  I have seen many users post full 5M desktop
screenshot image attachments instead of cutting and pasting just the
text of the output.  Don't send images of the desktop with a text
window with some error output.  Just send the text of the output.
This is becoming a problem and so I mention it just to get more
visibility into the problem.

Full disclosure: I am one of the mailing list admins and do a lot of
anti-spam and other maintenance behind the scenes.

> > FYI, you also emailed me your answer. I don't know if that is custom
> > (or even a slip) but anyway, it is not needed as I am happy to use
> > Gnus for Usenet.
> 
> I hit `Reply All', because I didn't want to reply only to you.  I
> could have edited the `To:' list to remove you and reply only to the
> list.  But some people who submit questions do not read the list.

First there were the bug reporting email addresses.  bug-PROJECTNAME
addresses.  (And confusingly also PROJECTNAME-bug addresses.)  GNU
used mailing lists for bug reporting.  Have a bug?  Email the details
to the project bug list.  Sounds good.  The M-x report-emacs-bug
function does just that action.

But would you require bug reporters to subscribe to a mailing list
before posting the bug report?  No.  That would be too high of a
barrier.  Requiring that would prevent many people from posting bugs.
GNU wants to make it easy and accessible for users to post bug
reports.  Therefore across the set of mailing lists all of the GNU bug
reporting mailing lists are open lists.  It is not required to be
subscribed to post messages there.  Just post your bug report.  When
responding to a bug report a responder will reply-all and include both
the original poster and the mailing list in the reply.  Unless the
poster specifically requests something different.

For many projects the *only* mailing list is the bug reporting mailing
list.  This is very common for small projects without a lot of
participation.  In such lists the bug list is used for *all*
purposes.  Meaning that not just bugs are reported there but all
project discussion is posted there.  It will be a mix of bug reports
from people who are not subscribed and discussion from people who are
subscribed.  For small projects where everyone knows everybody they
seem to like it that way.  It has a cozy country home feel.  In those
cases again most people reply-all because there is no guideline to do
otherwise and not replying to a bug-reporter is worst than CC'ing a
regular team member.

After a project has grown to have a large participation base like
Emacs has then there will be too much for a single mailing list.  Then
there will be many specific lists.  One for development, for software
commits, for help, for translators, and so on.  These new lists such
as the help-PROJECTNAME lists will be split off from the bug lists.
For the most part no one knows any other rules and therefore people
reply-all out of inability to do anything different.

Also here is my editorical opinion for whatever it is worth.  Some
people on these mailing lists will have been using mailing lists since
the beginning of email.  They will be familiar with netiquette
cocerning mailing lists.  They will pretty much do the right thing and
not complain too much when others do not.  But for a huge influx of
newcomers from IM and Twitter and Facebook the entire concept of email
is that it is something that only old people use.  This message of
mine is already TL;DR.  Using a reply-all button with the mouse will
be the limit of the amount of work they are willing to put into
things.  When I talk to people face to face and try to describe when
you should reply privately, when to reply-all, and when to list-reply
they look at me with an incredulous expression and say that it is too
hard.  And so reply-all as the lowest common denominator is the most
generally used way to reply to the GNU mailing lists.  For the most
part I have stopped complaining about getting direct CC's but I will
note that it is a pain for me and causes more work for me when trying
to help people.

In any case, the root cause of the problem is that for bug reporting
the bug reporting mailing lists must be open.  We cannot require
people to subscribe to post to them.  And therefore we reply-all
there.  And that behavior has carried forward to all of the subsequent
mailing lists.

I can easily tell if the person is the original poster or if they
responded to the mailing list.  If they responded then I know they
read the mailing list.  In those cases I never send them a CC.  I will
only keep the original poster in the CC list and drop all others.
Also if I recognize that the person is a regular participant then I
know they don't need a CC and I drop them from the CC list.

If you do not want a CC then I suggest that you include a

  Mail-Followup-To: help-gnu-emacs@gnu.org

header in your email.  That will direct mail clients that respect it
to follow your wishes and to follow-up to the mailing list.  You can
observe the header on my messages.  It isn't a universal standard.
But it is as much of one as will ever happen again these days.  It is
still useful regardless.

> > Yes, but I was wondering more if there were any guidelines how to
> > interact in this very group. Like how much context to provide, and
> > stuff like that. If you use some special notation to highlight
> > commands. Etc.

Lastly I wanted to say that the time to write up documentation is when
it is fresh in the head.  When people have questions are the time to
get those questions answered and to write it down.  If you were
motivated to write down what questions you had concerning the mailing
lists and how to operate with them then I think that would be valuable
to answer and to document.  I would like to capture that and make that
available to others.

Unfortunately the wiki was cracked by spammers some time ago and no
one has had the resources to make it work again.  Otherwise I think a
wiki page for this would be most appropriate.  Regardless of that I
would still value seeing the questions people have about the mailing
list and producing some type of documentation to answer them.

Whew!  And that only scratched the surface.

Bob