On Fri, Feb 22, 2019 at 11:11 AM Karthikeyan wrote:
> I would also suggest cleaning up the existing set of easy issues where the
> issues was tagged as easy initially followed by discussion about how the
> though easy has other concerns like backwards compatibility due to which it
> can't be merg
> I'm 100% in favor of discouraging regular contributors from fixing them
>
This would be nice too. Speaking from my experience, it's hard to leave
the comfort of what looks to be a quick win (by submitting a PR on an easy
issue) and moving on to something where you're more unsure. But...
> -
>
> I agree completely. We normally add the "Easy" or "Easy (C)" keywords to
> mark these (the latter for issues that involve C code), and these are
> collected under the "Easy issues" link at the left hand side of the
> tracker.
>
> Any reason to change from this process?
>
>
Thanks for asking abo
Hello!
Due to the upcoming sprints at PyCon, there will be issues marked in the
bug tracker as 'Good first issues'. Please do *not* submit pull requests
for these as it is difficult to find suitable issues.
Instead of working on these issues, I'd like to propose a much more
difficult challenge t
http://www.esecurityplanet.com/threats/git-svn-and-mercurial-open-source-version-control-systems-update-for-critical-security-vulnerability.html
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr