[Python-ideas] Using an appropriate tone in emails (was: Adding a thin wrapper class around the functions in stdlib.heapq)

[bunslow]

On Mon, Nov 27, 2017 at 4:36 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 27 November 2017 at 21:59, Nick Timkovich <prometheus235 at gmail.com>
> wrote:
> > On Mon, Nov 27, 2017 at 8:17 PM, Brett Cannon <brett at python.org> wrote:
> >>
> >> But calling it "atrocious" and so bad that it needs to be fixed
> >> "immediately" as if it's a blight upon the stdlib is unnecessarily
> insulting
> >> to those that have worked on the module. To convey the feeling that you
> >> think an OO wrapper would be helpful as the current design doesn't work
> for
> >> you, you could just phrase it as I just did to get the same point across
> >> without insulting anyone. Basically if you wouldn't like your own work
> >> called "atrocious" by someone you respect, then it's probably best to
> not
> >> use that phrasing when talking about a stranger's code either.
> >
> >
> > Sorry for the curt tone, I did lose some sight on the code being
> designed by
> > people rather than a faceless organization. My intention wasn't to
> disparage
> > the original authors but sprung more out of my frustration and perception
> > from that thread and those before that the status quo would not change
> and
> > that if a contribution was proffered, would simply be dismissed or
> ignored.
> > To motivate any change, there must be some argument levied against the
> > status quo, but hopefully I can articulate it better.
> >
> > That little corner is something I'm interested in, and not having
> > contributed to CPython before, I'm unsure how it "really works". The
> steps
> > at https://devguide.python.org/stdlibchanges/ suggest trying to elicit
> > community feedback from the lists as a step, so negative feedback tends
> to
> > kill the enthusiasm to actually make the PR. In the absence of code,
> > concrete arguments are almost impossible as we're discussing the shape of
> > clouds.
>
> In my experience (and this reiterates Brett's point) the proposals
> that get the best responses are those that are presented positively -
> instead of focusing on the (perceived) problems with the current
> situation, describe the benefits that will come from the proposed
> change. If you can't do that, then it's unlikely there is enough
> justification for a change. Certainly, negative feedback can be
> demotivating, and when you have a great idea and all you hear is "but
> what if...?" it's hard to remain positive. But you're not going to get
> better feedback if you criticise - at best, people will stop
> listening, and you'll have avoided some of the arguments, but at the
> cost of no-one being willing to support your proposal and so it dies.
>

My first submission to this list was predicated on what I'd read in PEPs --
and many of those, since they recommend major-enough changes to require a
PEP, have sections (often lengthy) dedicated to "what's wrong with the
status quo". My attempt to imitate that obviously crossed some boundaries
in retrospect, and of course now that it's brought up here I see that
spinning it as "what can be done to make it better" is psychologically much
more effective than "why the current way sucks" (because semantically these
are either approximately or exactly the same). But that's where it came
from, at least with some of my earlier threads, and I suspect the author of
the topic message of the OP will have a similar sentiment.

(One major example I can point to is PEP 465 -- because it proposed such a
major change to the language, literally half its text amounts to "what's
wrong with the status quo", quantifiably and repeatedly. It was also a
highly persuasive PEP due in no small part to its "why current things suck"
section.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171127/1e1ca0b9/attachment.html>