[Outages-discussion] Outages vs Outages-Discussion

[Grant Taylor]

On 12/11/19 8:51 PM, Jeremy Chadwick wrote:
> I certainly do not expect replies to my outages@ posts will end up 
> going to outages-discussion at .

Would you say the same if replies to outages had gone somewhere other 
than the list for the last X years?

Yes, the proposal is a change.

Is said proposal good or bad?  ¯\_(ツ)_/¯

> This is not intuitive.

I'll give you "unexpected" based on "current and previous behavior".

> No mailing list I've used for the past 30 years has behaved that way.

I've been subscribed to multiple "announcement" mailing lists or similar 
"broadcast" mailing lists that direct replies somewhere other than the 
mailing list.  Some direct to an info@ or customer-service@ type 
positional email address.  Others direct back to the submitter (either 
explicitly or by lack of directing it to the list).

> Usenet also did not behave that way.

It sure can.  That's what the "Followup-To:" header is for.  In fact, 
it's not uncommon to see it, particularly when posting to multiple 
newsgroups initially.

> Web forums/threads do not behave that way.

Broadcast / announcement web ""forums (read: news pages with no comment 
field) sure do.

> I often refer coworkers and colleagues to outages@ threads (via the 
> Mailman archive web interface) when there are reported problems.
Why couldn't you refer them to the outages-discuss thread?

Especially if outages-discuss included the original message?  (See below.)

> To tell people "if you want to read the replies to that issue, 
> you'll need to visit a different URL of the OTHER list, which 
> is..." is bizarre.

That's a UX issue, one that I think that there are options to improve. 
(See below.)

> Nobody will take such a list seriously.

I disagree.

Revised suggestion:
  · All new messages to outages@ also get posted to outages-discussion at .
  · All replies to outages@ get held for moderation.

Thus outages@ would be for new messages and moderator approved replies. 
  Outages-discussion@ would be everything.

People can pick the low volume outages@ or the higher volume 
outages-discussion at .

> In summary, I am against the Reply-To recommendation.

Fair enough.

> That said:
> 
> I am very much in favour of solving the actual problem, which I 
> believe is of a social nature.  We should not be trying to solve bad 
> list netiquette via technological hoops.  Instead, I suggest direct 
> action by list moderators: lecture those who don't understand proper 
> list etiquette, and yank the subs of (and blacklist) repeat offenders.

I like the spirit.

But my experience is that there will always be people who can't / won't 
be taught.

> Yes, the problem we're discussing will keep happening as new people 
> join the list (and don't read list rules or follow proper netiquette), 
> but that's life.

So, by  your own words, what you're suggesting will have known problems 
and will fall short of preventing discussion on the outages@ mailing list.

> More than ever today people need reminded of RFC 1855.  Its age 
> doesn't matter; much of its content still applies.

Sure.

What about the people that are perfectly well aware of it and choose to 
ignore it?

> I think the SNR overall on these lists is tolerable, barring outages of 
> "major entities" (ex. Google, FB, etc.).  During such times, I expect 
> increased noise, albeit briefly (e.g. for the day).

Individual subscribers can configure filters in their MUA to mark 
replies (messages starting with Re:, etc, or contain the References: / 
In-Reply-To: headers) as read.  Thus new messages will seek attention, 
and allow them to ignore other messages.

I guess my opinion of society and faith in people's (lack of) netiquette 
that I trust technical solutions a LOT more than I trust people to do 
the correct thing.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/outages-discussion/attachments/20191211/2a1ac436/attachment-0001.p7s>