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

[Steve Dower]

On 21Feb2019 1258, Cheryl Sabella wrote:
>     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 about this.  The intent isn't to stop the use of the 
> 'easy' keyword, but to try to reserve some tickets for May.  If they are 
> just marked as 'easy', then there could be more of a risk that someone 
> would work on it before the sprints.  By assigning them to Mariatta, it 
> will serve the dual purpose of trying to reserve these as well as making 
> them easier to find later on.  I think the equivalent would be the 
> ability to add an additional tag to GitHub issues, such as when there's 
> a 'good first date', 'help wanted' and 'sprint' tag on the same ticket.
> 
> But, I also don't want to complicate the current process, so I apologize 
> if my idea isn't constructive.

I'm just trying to keep things easy to search.

Keywords are the bpo equivalent of GitHub tags, so if we want a 
"saved_for_sprint" tag then we should add a new keyword. (In my 
experience, "sprint" tags on GitHub are normally used on PRs to indicate 
that they were created at a sprint.)

I'm sympathetic to wanting to have tasks for the PyCon sprints, but at 
the same time it feels exclusionary to "save" them from people who want 
to volunteer at other times. Having paid to attend PyCon shouldn't be a 
barrier or a privilege for contributing (though it's certainly a 
smoother road by having contributors there to assist, which is why other 
conferences/sprints are keen to have core developers attend as mentors).

I'm 100% in favor of discouraging regular contributors from fixing them 
- we should be *generating* easy issues by describing how to fix it and 
then walking away. I'm just not entirely comfortable with trying to also 
hide them from first time contributors. Either way, I'll keep marking 
issues as Easy when I think they are good first contributions.

Cheers,
Steve