[Python-Dev] "Good first issues" on the bug tracker

Karthikeyan tir.karthi at gmail.com
Sun Feb 24 06:31:32 EST 2019

On Sun, Feb 24, 2019 at 1:07 PM Terry Reedy <tjreedy at udel.edu> wrote:

> On 2/23/2019 2:50 PM, Cheryl Sabella wrote:
>   AM Karthikeyan <tir.karthi at gmail.com> wrote:
> >     I would also recommend waiting for a core dev or someone to provide
> >     some feedback or confirmation on even an easy issue's fix since it's
> >     easy to propose a fix to be later rejected due to various reasons
> >     resulting in wasted work and disappointment.
> >
> > Agreed, but perhaps the most helpful way to do that is to propose the
> > fix in a comment on the bug tracker and then, if a core dev or expert
> > says it's a good idea, then move ahead with it?
> I agree with both of you as to what contributors, especially new
> contributors, *should* do.  But they sometimes race to 'grab' an issue
> by (prematurely) submitting a PR, sometimes after ignoring coredev
> comments and disagreements.  I have occasionally said on an issue that a
> PR was premature.

I guess it could be due to the initial excitement in contributing to a
large project. I must admit I too did some mistakes in my initial set of
PRs along similar lines. I guess it's one of the things both someone
contributing new and a regular contributor should learn over the course of
time that there are cases where the solution might seem important from the
perspective of the contributor in getting code merged but provides less
value amidst other factors like code maintenance, backwards compatibility,

There is also high interest in creating a PR and less on reviewing other
PRs (1020 open PRs on GitHub) which could be a separate topic on its own.
There could be some action or motivation on making sure there is a balance
in the incoming PRs and review bandwidth since there might be a stage where
there is a lot of interest or efforts in getting new contributors who
create a PR with less bandwidth to review resulting in potentially making
them disappointed in having work not reviewed. We should be getting new
people on board and it's not that I complaining but this is something that
the steering council could discuss upon regarding reviews and there was a
recent thread on it [0]


Karthikeyan S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190224/3bb5c3d0/attachment.html>

More information about the Python-Dev mailing list