[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Guido van Rossum]

Guido van Rossum added the comment:

Thanks Berker! I agree the discussion shouldn't be narrowly about the
keywords and how to assign them -- we could also do a better job of guiding
new contributors. From Shubeksha's blog post it seems that we're doing
almost nothing in this area -- people scanning the easy issues are quickly
turned off.

FWIW in mypy we've got two separate keywords -- one for newbie issues and
one for easy issues. The newbie issues are meant to be easy enough to guide
people through their first contribution ever. The easy ones are easy once
you have mastered the pull request workflow etc.

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Stephen J. Turnbull]

R David Murray writes:

 > (At least, I think one can retire tags, I haven't actually
 > checked).

I've done it on the XEmacs tracker, so it used to work fine, but that
was a while ago.

Steve
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Nick Coghlan]

Nick Coghlan added the comment:

OK, I've created the "easy (C)" keyword: http://bugs.python.org/keyword18

I've left the existing "easy" keyword alone for the time being, as the Python 
vs Documentation split is already implied by the component, but changing the 
keyword to "easy (Python)" would confuse that distinction.

So the next step would be to review the current "easy" list and switch any C 
issues over to "easy (C)"

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Nick Coghlan]

Nick Coghlan added the comment:

Guido: good points, so I've instead filed 
https://github.com/python/devguide/issues/38 to discuss updating the Triaging 
section of the devguide with a bit more guidance on when it's a good idea to 
set these keywords.

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Guido van Rossum]

Guido van Rossum added the comment:

The term "well defined" would not resonate with people looking for starter
bugs. Read this piece for an overview of how other projects (esp. Mozilla)
try to lure new contributors, and how that's seen by someone eager to
contribute:
https://medium.com/@shubheksha/finding-your-first-open-source-project-or-bug-to-work-on-1712f651e5ba#.i860som7g

On Thu, Sep 22, 2016 at 1:18 AM, Nick Coghlan <
metatrac...@psf.upfronthosting.co.za> wrote:

>
> Nick Coghlan added the comment:
>
> If we're tinkering with the "easy" tag, would it make sense to switch to a
> more objectively definable phrase like "well defined (Python)" and "well
> defined (C)"?
>
> The reason I ask is that good starter issues for folks that just want to
> work on CPython in general rather than having a particular problem they
> want to tackle tend to be either:
>
> - bugs with a clear reproducer and a relatively straightforward fix; or
> - API addition/changes that already have in principle core dev approval
>
> Other open issues tend to be a bit more at risk of getting bogged down in
> design discussions that go in circles or attempts to find a core dev
> willing to sign off on the change, which can be a bit disheartening for
> folks that only have limited time to contribute.
>
> The other reason I suggest this is that even a well defined issue may
> still be difficult for a true novice to tackle, but they will at least have
> a clear goal to aim for. For folks that are experienced devs and merely new
> to CPython specifically, the coding side may be easy for them, but they'll
> still get a chance to run through the the contribution workflow without
> having to invest too much time in seeking approval for the change itself.
>
> --
> nosy: +ncoghlan
>
> ___
> PSF Meta Tracker 
> 
> ___
>

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Nick Coghlan]

Nick Coghlan added the comment:

If we're tinkering with the "easy" tag, would it make sense to switch to a more 
objectively definable phrase like "well defined (Python)" and "well defined 
(C)"?

The reason I ask is that good starter issues for folks that just want to work 
on CPython in general rather than having a particular problem they want to 
tackle tend to be either:

- bugs with a clear reproducer and a relatively straightforward fix; or
- API addition/changes that already have in principle core dev approval 

Other open issues tend to be a bit more at risk of getting bogged down in 
design discussions that go in circles or attempts to find a core dev willing to 
sign off on the change, which can be a bit disheartening for folks that only 
have limited time to contribute.

The other reason I suggest this is that even a well defined issue may still be 
difficult for a true novice to tackle, but they will at least have a clear goal 
to aim for. For folks that are experienced devs and merely new to CPython 
specifically, the coding side may be easy for them, but they'll still get a 
chance to run through the the contribution workflow without having to invest 
too much time in seeking approval for the change itself.

--
nosy: +ncoghlan

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Brett C.]

Brett C. added the comment:

If Berker is comfortable with his assessment then we can ignore my 
"conservative" suggestion and just rename the current label "easy (Python)" and 
reclassify as necessary.

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[R David Murray]

R David Murray added the comment:

I'm not sure what you mean by "be conservative".  Leave the current tag alone 
and add "easy (C)" and just apply it to the identified C issues?  That would 
actually make sense.  We could also add a *new* 'easy (python)', and retire the 
current 'easy' tag, which means it would live on in the issues it is already 
set on, but couldn't be set on new issues.  (At least, I think one can retire 
tags, I haven't actually checked).

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Brett C.]

Brett C. added the comment:

The other option is to be conservative and mark the current easy issues as 
"easy (C)" and then adjust accordingly.

And I'm totally happy w/ David's interpretation of the bikeshed's plans as it's 
shorter.

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Guido van Rossum]

Guido van Rossum added the comment:

Go for that!

On Mon, Sep 19, 2016 at 11:12 AM, Berker Peksag <
metatrac...@psf.upfronthosting.co.za> wrote:

>
> Berker Peksag added the comment:
>
> I don't see a lot of C issues in the "easy issues" list. I agree that some
> of them (including a few pure Python ones) shouldn't be classified as
> "easy".
>
> I'd say we should remove the following issues from the list:
>
> * http://bugs.python.org/issue1100942 (requires knowledge on times,
> Python and C)
> * http://bugs.python.org/issue25026
> * http://bugs.python.org/issue18156
> * http://bugs.python.org/issue20265
> * http://bugs.python.org/issue10374 (requires Windows knowledge)
> * http://bugs.python.org/issue11697 (needs careful review)
> * http://bugs.python.org/issue17561
> * http://bugs.python.org/issue17179
>
> --
> nosy: +berker.peksag
>
> ___
> PSF Meta Tracker 
> 
> ___
>

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Brett C.]

Brett C. added the comment:

"easy doc issue" wouldn't be hard to add either.

Does anyone else have any feedback on this?

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Guido van Rossum]

Guido van Rossum added the comment:

Those two sounds great -- maybe also add "easy documentation issue"?

On Sun, Sep 18, 2016 at 10:57 AM, Brett C. <
metatrac...@psf.upfronthosting.co.za> wrote:

>
> Brett C. added the comment:
>
> Adding a new keyword isn't hard; it can be done from
> http://bugs.python.org/keyword with the right privileges.
>
> What would you want the current keyword to become and the new one to be?
> "easy C issue" and "easy Python issue"?
>
> --
> nosy: +brett.cannon
> status: unread -> chatting
>
> ___
> PSF Meta Tracker 
> 
> ___
>

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/

[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not

[Guido van Rossum]

New submission from Guido van Rossum:

I've noticed we have a lot of "easy" issues on bugs.python.org that are only 
easy if you're fluent in C. We have (potentially) many new incoming 
contributors who aren't (yet) at that level but who would be happy to help out 
with other tasks that don't require C. They appear to be looking through the 
tracker for "easy" issues and are put off by the C requirement. Would it be 
possible to add another keyword that we can use to distinguish between the two? 
We could then also add a second search to the sidebar so newcomers can easily 
find the category they care about.

--
messages: 3162
nosy: guido
priority: feature
status: unread
title: Python tracker needs two classes of "easy" issues -- requiring C or not

___
PSF Meta Tracker 

___
___
Tracker-discuss mailing list
Tracker-discuss@python.org
https://mail.python.org/mailman/listinfo/tracker-discuss
Code of Conduct: https://www.python.org/psf/codeofconduct/