[erlang-questions] Announcing Erlang.org Code of Conduct

[Benoit Chesneau]

These discussions about top posting (which is the default in most mua now)
seem quite frivolous...

Top posting is about providing an *over*view , what generally follows is
the context of this overview (ie the previous mail). Some are also
attaching this context. Bottom posting is about answering to a context.
Some prefer to answer inline. Some are mixing top posting and inline
content to provide a more accurate message (ie. giving an overview and
answering in detail)

See all of these methods answers to different types of communications.
Imposing one over the other is a nonsense imo... As for the 80 chars limit
in mail I stopped since a long time to have it, since i had to do it
manually and like Loic and others noticed it provides different results
depending on the machine or mua.

Anyway we can have long debate about it but it seems weird to have it in a
thread about a CoC which goals is to welcome others.

- benoit

On Thu, Mar 26, 2015 at 7:14 AM Vincent de Phily <
vincent.dephily@REDACTED> wrote:

> On Thursday 26 March 2015 12:09:12 Loïc Hoguin wrote:
> > You say this but you have the same problem as zxq9. In my client your
> > "properly formatted email" has line breaks about every 80 characters,
> > which results in every second line being exactly one word. It wouldn't
> > be like this if you or your client didn't put those line breaks.
> >
> > It's interesting because you say the writer has to format his email
> > keeping in mind how people will read it, in an email that is actually
> > much harder to read for me than top posting.
>
> I'm sorry to hear that. I was aware of clients that couldn't display more
> than 80 chars, but it seems yours has a lower limit.
>
> The cut at 78 chars is indeed my MTU's doing. Having every second line
> consisting of just one word is your MTU's doing. See the archives :
> http://erlang.org/pipermail/erlang-questions/2015-March/084025.html
>
> I find such a receiver-side display limit anachronistic, but it seems that
> it can't be helped, so here's a mail reconfigured to cut at 74 chars for
> your viewing pleasure.
>
> I'm on record saying that 74 chars is a silly limit, and I'd prefer if
> word-wraping was only done at display time, but plaintext being what it
> is, wraping must still be done at writing time in some cases (for example
> when indenting bullet points). Html emails may be a solution, but they're
> a horrible one.
>
> So we still have to deal with write-time wraping at a lowest common
> denominator cutoff point. Thanks for reminding me that 78 chars was still
> too wide; are you sure you can't upgrade ? :p
>
>
> > Considering the very large number of clients and possible
> > configurations, I find it very odd to blame the one writing the email
> > instead of the client being used to read said email.
>
> There. I blamed your mail reader for pointlessly wraping my
> conservatively-sized lines. Sometimes it's the writer's MTU, sometimes the
> reader's, sometimes the MTA, sometimes the human... Let's deal with each
> separately.
>
>
> > An email isn't a PDF, it *will* display differently everywhere.
>
> Yes, I've mentioned that issue above.
>
>
> > Should I, as an email writer, be careful about using the ')' character
> > just because many clients will convert it to a smiley?
>
> You should, on any medium, be aware of your reader's general limitations.
> That doesn't mean that you absolutely must deal with every silly case.
> Accidental smileys are frequent enough, especially with computer code, so
> I hope that the reader has a way to turn them on and off. Like it should
> have a way to temporally use monospaced fonts when someone sends an ascii
> diagram.
>
>
> > Though I'm guessing your answer there is "no because my client doesn't
> > do it and my client is right and all others are wrong".
>
> I hope I don't sound that obnoxious ?
>
>
> > It is trivial to detect the rest of an email is just a quote and the
> > client should indicate that (it would also be useful for those who do
> > quote inline but leave a large quote unanswered at the end),
>
> All MTUs I know display quotes a bit differently, sometimes even
> collapsing them by default. That makes parsing them easy for the user
> (though there's still that gmail bug that puts the first line of the reply
> inside the quote...), but it's still be nice to avoid having to parse the
> quote if the quote wasn't necessary to begin with.
>
>
> > just like it should be trivial for my client to change the flow of text
> > to make it readable instead of the mess it makes right now.
>
> My client (kmail) happens to help with that by re-adding the proper quote
> markers when I hit enter inside a quote, but I'd say that the general case
> is not trivial. The only MTU that I remember being good at that is gnus
> (an emacs mode), most other MTUs I've seen don't help at all.
>
>
> > I find it fascinating that the code of conduct has only had the opposite
> > of the intended effect so far.
>
> The paragraphs about style have been removed from the CoC, so this thread
> is not really about CoC anymore. And as much as I dislike top posting,
> it's a trivial issue compared to verbal abuse.
>
> --
> Vincent de Phily
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150326/1ed9e81a/attachment.htm>