Should non-security 2.7 bugs be fixed?

[Rick Johnson]

On Monday, July 20, 2015 at 1:47:00 AM UTC-5, dieter wrote:
> Thinking of myself, I am not sure. Ensuring the quality of
> a "distribution" goes far beyond a single bug fix. While I
> usually are ready to share a bug fix I have found, I am
> reluctant to get involved in the complete quality
> ensurance process (such as the test suite, review process,
> style guides, ...).

Of course. I believe there are many folks out there like
yourself, who come across this or that bug, but don't bother
sharing the patch because of the reluctance to deal with red
tape or fear of a brow beating.

Participation, on a regular basis, requires a special kind
of person with special talents. For example: Terry Reedy has
been working over at "pybugs" for years. I don't think
everyone wants to be, or can be, a Terry Reedy. But i do
believe the current system is presenting obstacles to those
that could offer help in whatever limited capacity they can
handle.


OUTLINE OF FOUR POSSIBLE LEVELS OF PARTICIPATION:

  LEVEL1: Anyone, no matter what coding skills they have,
  can bring attention to a problem, and allow someone else
  to write the code. "HEY, I FOUND A PROBLEM -> BLAH, BLAH,
  BLAH". Also, not all programmers are experts with the
  written word. And a poorly described problem can result in
  it never getting the attention is deserves. We not only
  need coders, we need writer who can peruse the complaints
  and reformat them for comprehension and coherency. We need
  a diversity of talent, and not just "code monkey talent",
  all forms!
    
  LEVEL2: Even someone with "sketchy knowledge" of the fix
  can write up an outline, or a list of steps that could be
  taken, in order to fix the problem. Possibly pointing out
  some of the subtle bugs that may crop up if not carefully
  considered. Very few of us know *everything* about every
  module or dark corner of Python. For example, I've talked
  with a few "grand masters", who had little or no knowledge
  of Tkinter or IDLE.
    
  LEVEL3: The next level would be to write draft code. Maybe
  the code would not even be considered "professional". But
  it could serve as a "rough draft" that a more experienced
  programmer can build from.
  
  LEVEL4 The last level is a fully functioning patch. This
  would be written, or approved by, one of the trustees.

And even if the "contributor" can only participate at level1
or level2, if they find the process is smooth, then they are
more likely to participate again. And as they become more
experienced, will offer help at a higher level of expertise.
I know the wheel is being re-invented all the time, simply
because of the obstacles inherent in the patching process.
  
There needs to exist a linear path from bug to patch. We
don't want Terry Reedy wasting his expertise on the first
two or three levels, no, we need to place him at a level
where his talents are not wasted reading ridiculous feature
requests that will never go beyond level1 or level2.

My point is, we're unproductive because: (1) we're scaring
away intermediate and specialized talents (2) and we're mis-
applying the limited talent we do have.