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

[Victor Stinner]

Hi,

Let me share with you (this mailing list) my experience with mentoring
and what we call "easy issue". First of all, almost all "easy issues"
are very hard issues: issues open for longer than one year, with many
comments, and nobody succeeded to come up with a solution (well,
otherwise the issue would be closed, no? ;-)). Does it mean that there
is no easy issue? Well, when someone creates a really easy issue, it's
usually fixed in less than 2 hours(!): either by a core dev who want
to relax their brain, or by a contributor eager to get more commits
under their name.

It's not uncommon that even if an issue is marked as easy (easy
keyword and [EASY] in the title), it's fixed by a core a dev. Or at
least by a "regular" contributor who wants to get more commits. For a
regular contributor, I see the point of getting more commits: getting
more visible. But in my criteria to promote a contributor as a core
dev, it's not enough. It's not with easy issue that you learn hard
stuff: trade off between backward compatibility and new features which
has to break it, write complex test, document properly a change, etc.

Does it mean that we don't need easy issue? No. For someone who really
starts from the beginning, easy issues are required. You cannot ask a
newcomer to immediately write the perfect PR at the first attempt with
a long list of strict requirements: complex tests, handle portability
issues, etc. You need to build a stair made of *small* steps.

What's the solution? I'm not sure. I decided to stop opening public
issues for my mentorees and instead give them easy bugs by private
email. Why? My main concern is the high pressure on an open issue: the
race to be the first to produce a PR. Recently, I opened a public
issue anyway but explicitly wrote that it's reserved for my mentoree.
Someone ignored the message and wrote a PR... It was a first time
contributor and it was really hard to me to reject the PR :-( (My
mentoree wrote a better PR with my help, at least a PR closer to what
I expected, obviously since I helped.)

I prefer to give unlimited time to my mentoree to dig into the code,
ask questions, write code step by step. I really hate the time
pressure of the race on open easy issues :-(

Now the question is: how can *you* find an easy issue? Well. In the
past, my real problem was that I didn't let anyone write the code that
I would like to write myself. I considered that nobody writes code as
well as I do... Sorry :-) It took me time to change my mind.

    Lao Tsu said that if you give a hungry man a fish,
    you feed him for a day,
    but if you teach him how to fish,
    you feed him for a lifetim

To better scale horizontally, I have to teach other people what I do,
to be able to distribute the work.

I am working hard against myself to stop writing all code myself.
Instead, I'm trying to explain carefully what I would like to do,
split the work into tasks, and distribute these tasks to my mentorees,
one by one. But I don't put my mentorees in a competition, each
mentoree has its own project which doesn't conflict with others.

Doing that takes me a lot of time: create tasks, follow tasks, review
PRs, etc. To be honest, right now, I'm mostly able to follow correctly
only one mentoree at the same time. The others are more "on their own"
(sorry!). As you may know, finding a task doable by mentorees is hard.
I have a lot of ideas, but many ideas will take years to be
implemented and are controversial :-)

I don't ask you to completely stop writing code. I ask you to not
write everything yourself, and sometimes give the simplest issues to
contributors who are eager to help you.

Victor