[Python-ideas] A tuple of various Python suggestions

[Nick Coghlan]

On 11 April 2016 at 07:24, Keith Curtis <keithcu at gmail.com> wrote:
> I personally find Python very stable, but the bug counts have been
> heading in the wrong direction:
> http://bugs.python.org/issue?@template=stats
>
> I recently discovered those charts, and they have valuable data that
> can be turned into action.

How? Are you offer to pay someone to bring them down? Are you offering
to work on it yourself? Are you offering to help with the current
workflow improvement efforts that are designed to make more efficient
use of the limited pool of available contributor time?

It's very easy to say "Hey, these metrics are going in the wrong
direction". It's very hard to do something productive about it, rather
than just complaining on the internet.

> My distributor of Python is Arch. I presume it is very close to what
> you guys release. That's just my example, but from what I've seen, few
> pay for a Python runtime.

Then you'd be incorrect (they may pay for it as part of something
else, like a Red Hat subscription, or an
Azure/AWS/GCE/Heroku/OpenShift account, but they're paying for it).

It's true that *open source and free software communities* are very
bad at ensuring the development processes for the software we use are
sustainable, but that seems to be because we're bad at supply chain
management in general and even more confused than most by the
difference between "duplicating an already existing piece of software
can readily be made zero cost" and "ensuring a piece of software
remains useful as the world around it changes requires ongoing
investments of time and money".

> I don't suggest guilt-tripping volunteers into fixing bugs. If you've
> got to dig a ditch, you can try to enjoy the sun. Getting the bug
> count under control is an admirable goal. The list is an opportunity
> to focus on the known problems real people care about most, and to try
> to deal with old issues before taking on new ones.

But is that a fun way for volunteers to prioritise their time, as
compared to working on things that interest them personally, or that
they otherwise find inherently rewarding?

Many of the oldest issues remain open because they're rare, easily
worked around, hard to fix, only arguably a bug, or some combination
of the above. Even reviewing them to see if they're still valid can be
time consuming.

A lot of projects deal with that problem by automatically closing old
issues that haven't been touched in a while, which seems to be a text
book case of gaming the system - once you treat "number of open
issues" as an important metric, you've created an incentive to
"default to closing", even if the underlying problem hasn't been
addressed.

> I don't recommend people fix bugs to help "corporations and large
> organizations". You won't be very motivated by that anti-capitalist
> mindset.

What anti-capitalist mindset? "If someone wants me to fix bugs for
their reasons rather than mine, they can pay me" is a
quintessentiallity capitalist attitude. I only add the "corporations
and large organisations" qualifier because they're more likely to be
able to afford to pay someone, and less likely to have volunteers
willing to work on their problems for altruistic reasons.

> People should fix bugs because it helps real Python users,
> and gets rid of barriers.

This is still guilt tripping volunteers - neither "you're not
volunteering enough" nor "you're volunteering for the wrong things"
are acceptable messages to send to folks that are already contributing
(and folks that send that message regardless of its inappropriateness
are a major factor in open source contributors burning out and
quitting community contributions entirely, so it has the exact
opposite effect of the intended one).

By contrast, it's perfectly reasonable to let folks that have *spare*
time they're willing to give to the community know that there are
plenty of opportunities to contribute and provide info regarding some
of the many areas where assistance would be helpful, as long as it's
accompanied by the reminder that a sensible and sustainable personal
priority order is "health, relationships, paid work, volunteer work".

Even putting that question of healthy priorities aside, it's also the
case that the vast majority of Pythonistas *aren't* affected by the
edge cases that aren't handled correctly, or they're using third party
libraries that already work around those issues. The latter is
especially true for folks working across multiple Python versions.

> I was teasing about you guys not being paid professionals, however, it
> appears that very few of you have the goal of getting the official bug
> count down. That is a big difference between amateurs and
> professionals.

As noted above, commercial projects tend to be far more ruthless about
culling old "We're not going to invest resources in addressing this"
issues. We prefer to leave them open in case they catch someone's
interest (and because politely explaining to someone why you closed
their issue report can itself be quite time consuming).

However, I'll also reiterate my original point: if you want a customer
experience, pay someone.

> If few people feel ownership of the official Python, it
> can be bad. Maybe the PSF could hire more with that mindset.

There's a big difference between "not offering a customer experience
for free" and not feeling ownership. Now, you may *want* a customer
experience for free, but that doesn't make it a reasonable
expectation.

> I don't
> know the solutions, but I am grateful to be able to send you a few
> words.

This isn't a case where articulating the problem is at all helpful -
we're well aware of the problem already (hence the metrics).

The PSF is also aware of the concern, but it's a longer term challenge
compared to other areas (such as the Python Package Index), so it's
not something we're interested in driving from the Board level at this
point in time.

Regards,
Nick.

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