[Python-Dev] Issues not responded to.

[R. David Murray]

On Sun, 02 Aug 2015 21:47:23 +0530, Rustom Mody <rustompmody at gmail.com> wrote:
> [Yeah I am a lurker on the mentors list but I dont see much *technical*
> discussion happening there]

Yes, it's a mentoring list for how to contribute, not for technical
issues, though we happily get in to technical issues when they arise.

> We could actually submit patches.
> Just that the priorities of the 3 parties -- teachers, students, devs --
> is clearly different:
>  - Teachers need to give/create a good learning experience
>  - Students need to shine, do well, excel...("show off" is not an
> inaccurate description)
>  - Devs need the language to progress and bugs to be fixed
> 
> Though these priorities are different I believe a symbiosis is possible.
> In particular, at least some of the -- for a dev -- 'ugly-bugs'  could be a
> challenge in an academic context.

The issues that haven't been responded to are *an* issue, but not in
fact our most pressing one.  The bigger problem, that a Fellow would
solve, is not fixing bugs at all (although in Django's case apparently
the Fellow does handle security issues...we have an active group of
committers who address those, so I don't think a Python Fellow would
need to write patches for those, just possibly shepherd them through).

The need is to do the "ugly" *job* of making sure that issues that have
patches get reviewed, the patches improved, and *get applied*, and, yes,
that all issues get a reply.  (This is actually a job I enjoy doing, but
all I've been managing in my unpaid time lately is trying to keep up
with tracker triage and making technical/procedural comments on some
issues.)

If we had the kind of support a Fellow would provide then your students
could actually get valuable feedback by submitting patches (as long as
they were willing to take patch criticism!).  I'm not *sure* that would
be a good thing, as it would increase the review load of patches from
less experienced developers, but personally I'd encourage it anyway to
help kids (and other less experienced developers) *become* good
developers.  Python has always had an educational mission, after all :)

Rob's suggestion of core devs trying to review one 'commit review' patch
a day (or whatever rhythm works for them) could move us toward this goal
without a Fellow.  I'm going to try to get back to doing that.  But
realistically, we can't count on busy people being able to make that
kind of time consistently available for free, or being interested on
working on parts of Python that, well, they aren't interested in.

> I will be teaching again to more advanced students this time
> If I could find a path through bugs of different challenge-levels we may
> get some bugs fixed...

Like I said, our problem isn't getting the bugs fixed, it is getting the
fixes *reviewed* and *applied*.  (Yes, there are some bugs that languish
because no one is interested in doing the grunt work to fix them, but
I bet that problem would take care of itself if people were more
confident that patches would actually get applied when completed.)

Having your students *review* and improve existing patches that haven't
been moved to 'commit review' and aren't being actively worked on would
be just as useful as finding bugs without patches to work on (and easier
to do).  I think it would just as valuable educationally, or perhaps
more so, because they have a starting point, learn about code quality,
and figure out how *improve* code (thus learning about better coding
practices).

Unfortunately there is no good path to finding "appropriate" bugs.  My
own technique, used for the pycon sprints, is just to hit 'random issue'
and evaluate the doability (ie: it's not hung up waiting for a decision
from core) and difficulty level and putting it on a list accordingly.
That does in some cases require enough experience with the codebase to
make those judgements, but there are a lot of issues that are fairly
obvious on their face as to how difficult they are.

--David