Re: About Emotional Opinions

> Therefore, good proposals are well-described; requiring participants to
surmise or deduce what you are proposing makes it more likely that you will
fail to gain their interest. The number of people that didn't understand
your proposal should be taken as an indication that it needs to be
better-described, not that they are making bad assumptions, have emotional
opinions, etc. Merely offering source code is not a good way to make a
proposal.

This is just a generalization. No matter how many times I explained it as
fact this time, I was very annoyed by the repeated perversion in favor of
preconceived notions. Again, speculation based on assumptions is permitted,
but predications based on assumptions is not permitted. Can you say that
you allow predications based on assumptions?

> Furthermore, please avoid ascribing motivations to others, since this is
so often a source of misunderstanding and contention. In particular,
characterising those who are trying to help you by explaining the
constraints which might affect your proposal as "emotional" is needlessly
inflammatory and, if it continues, may be cause for action under RFC3934.

This is a clear error. The emotional statement is the stated result, not
the motive. The emotional statement is not to be inferred, but is the
written word itself. Therefore, your opinion is wrong from the very
beginning. Based on your premise, there is no emotional expression that
appears in any text and there is no emotional statement. This is clearly a
wild error. Trying to forcefully justify an obvious injustice leads to
ridiculous claims like this one.

2023年12月10日(日) 9:36 Mark Nottingham <mnot@mnot.net>:

> I don't know who I'm addressing this to, since my understanding is that
> the name given translates to "name." Of course, there is no requirement to
> give your real name on this mailing list, but you may find that anonymity
> makes it less attractive for some to engage in discussion with you.
>
> With that said -
>
> Succeeding in standards work requires engagement in good faith. As has
> been pointed out, everyone participates here because they want to; no one
> is compelled to respond to a message, or put work into an effort they
> aren't interested in.
>
> Therefore, good proposals are well-described; requiring participants to
> surmise or deduce what you are proposing makes it more likely that you will
> fail to gain their interest. The number of people that didn't understand
> your proposal should be taken as an indication that it needs to be
> better-described, not that they are making bad assumptions, have emotional
> opinions, etc. Merely offering source code is not a good way to make a
> proposal.
>
> Furthermore, please avoid ascribing motivations to others, since this is
> so often a source of misunderstanding and contention. In particular,
> characterising those who are trying to help you by explaining the
> constraints which might affect your proposal as "emotional" is needlessly
> inflammatory and, if it continues, may be cause for action under RFC3934.
>
> Finally, please avoid using the mailing list for administrative matters,
> such as e-mail delivery issues.
>
> The area you are considering has had considerable previous discussion and
> experimentation over several years, and other participants are attempting
> to give you the benefit of that experience. You will find that if you
> engage in good faith and accept that you may still need to learn more,
> others will do the same.
>
> Cheers,
>
>
> Mark Nottingham, Working Group Chair
>
>
> > On 10 Dec 2023, at 5:37 am, 姓名 <falsandtru@gmail.com> wrote:
> >
> > > pretty clear now that
> > > nothing constructive can get out of this thread at all anyway
> >
> > There are no facts to support this and it is off the subject of
> emotional opinion. The subject is whether this mailing list allows such
> replies despite the fact that it is very difficult to have a constructive
> discussion on the emotional responses excerpted below.
> > > 50-100 bytes per what ? Per header ? per request ? Per 10kB of headers
> > > sent ? You just sent raw numbers without *any* explanation.
> >
> > This is a breakdown of the compression ratio and the explanation is
> given first. He just didn't understand the explanation.
> >
> > > Huh ? No sure what you mean.
> > > Please stop rehashing this non-sense. I'm trying to help you get your
> > > proposal easier to review and understand. If you want to insult me all
> > > the time, go find someone else to review it.
> >
> > He is just misunderstanding and getting angry on his own. I have already
> explained that many of the problems you point out are not unique to my
> proposal, as they would occur even if compression ratios were improved in
> other ways.
> >
> > > I have more productive things to do of my time.
> >
> > This is a supremely emotional and unnecessary statement.
> >
> > It is impossible to continue a constructive discussion when you make
> emotional statements like this alone, assuming that what has already been
> explained to you by email has not been explained to you. Or are these
> statements allowed on this mailing list?
> >
> > 2023年12月10日(日) 2:53 Willy Tarreau <w@1wt.eu>:
> > On Sat, Dec 09, 2023 at 06:05:33PM +0100, Julian Reschke wrote:
> > (...)
> > > I would recommend that you reset the discussion, and come up with an
> > > updated coherent proposal that tries to address the questions that
> Willy
> > > asked.
> >
> > All, I just wanted to let you know that I've stopped responding to
> > these provocative messages as it has become pretty clear now that
> > nothing constructive can get out of this thread at all anyway, and
> > I don't think there's any point pursuing this "discussion".
> >
> > Cheers,
> > Willy
> >
>
>

Received on Sunday, 10 December 2023 08:23:07 UTC