[Python-Dev] Why wasn't I consulted [was How far to go with user-friendliness]

[Nick Coghlan]

On 15 July 2015 at 12:07, Steven D'Aprano <steve at pearwood.info> wrote:
> On Wed, Jul 15, 2015 at 10:59:50AM +1000, Nick Coghlan wrote:
>
>> Remember folks, "Why wasn't I consulted?!?!?!?" is one of the more
>> obnoxious behavours we can inflict on fellow open source maintainers
>> giving us the gift of their time and energy.
>
> Nick makes a good point, but it's more complicated than that.
>
> OpenSource is not just a family of licences. It is also a social
> movement, a culture, even a brand. We spend a lot of effort trying to
> get people to care, not just intellectually but also emotionally, and
> then when they react emotionally we're dismissive and tell them they're
> being obnoxious. Maybe they are, but if so, that's the price you pay for
> having people care.

Aye, there's definitely a balance to be struck (and *me* telling folks
not to be passionate about topics they care about would be the height
of hypocrisy).

The kinds of questions I'm encouraging folks to ask themselves to help
calibrate our degree of concern are:

* What change are we asking for?
* What will the practical end user benefit of that change be?
* What will the near term maintainer cost of that change be?
* What will the long term maintainer benefit of that change be?

Those are the questions other people are going to want answers to
anyway, so it makes sense to ask them of ourselves first.

In the case of partially reverting this change to Mock objects, the answers are:

* "Restoring support for 'assret_*' methods on Mock objects"
* "End users will be able to access their 'assret_*' methods on Mock objects"
* "Maintainers would need to modify the check itself and the related
tests and documentation"
* "Maintainers won't have to explain why 'assret_*' methods are
blocked and other 'assert_*' typos aren't"

Thus, the case for spending *any* time on reversion is incredibly
weak, even if folks agree with the premise that blocking *any* typos
at all is undesirable.

Robert's suggestion is different, as it focuses on addressing the near
term concern with a solution that genuinely improves the API design:

* "Move Mock assertions from methods to module functions"
* "End users will gain from clear structural separation between
Mock'ed methods and Mock assertions, such that method name typos don't
result in silently ignoring test failures"
* "Maintainers would need to design the new API and device a
recommended transition plan for end users that accounts for end users
wanting to support multiple Python versions"
* "Once the migration from the old API to the new API is deemed
complete, maintainers should eventually find that the improved
separation of concerns between Mock'ed methods and Mock assertions
makes the module easier to maintain"

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia