Cpython Bug Tracker: The broken promise of the Easy issue tag — My thoughts
Recently, Guido van Rossum wrote to the Cpython core-mentorship mailing list, an email with the title “The trouble with “Easy” issues”. Many people related to the subject of how it is hard to find a really easy issue on the Cpython bug tracker. They pointed out the fact that most easy issues are fixed in minutes by core developers and other contributors.
Well, like I said in my last blog on my experience contributing to Cpython, my first attempt to get a first time issue on the bug tracker, was a total fail. One thing that comes to mind quite quickly is Cpython has a bit of complexity. Am not saying this to scare anyone, that is how it appeared the first time to me at least. I needed to know a little more compared to other open source projects I contributed before.
In fact one time, I said this to a question in a chat where I was asked how to encourage more people of color to contribute. I replied :
I cant speak for all colored people..but personally I haven’t heard anything alarming yet in the python community. fyi I dont mind direct questions. What am trying to decode is why contributing to Cpython was hard before I got mentorship.
We can not blame triagers for tagging issues as easy when they don't seem easy because easy is relative from individual to individual. Even If we trusted new contributors with tagging easy issues, as they grow in their knowledge of the project, hard issues start looking easy to them too so they are likely to do the same.
The best we can do to aid new contributors understand the bug tracker in order to start contributing in my opinion is more about making improvements in what we post on the tracker under a given issue.
I was lucky to have started through mentor-ship and this meant I worked on some issues that were given to me outside the bug tracker. And I discussed these off the tracker with my mentor but as time goes on, the honey moon phase stops and you have to start figuring out somethings yourself. Plus individual mentor-ship doesn't scale as there are more mentees than mentors.
The following will aid new contributors in finding something to work on;
- Clearly document issues.
- Some Pointers to a solution.
- Decision making.
- Fix Post PR barriers too.
Clearly Document Issues
When you have worked on Cpython for 10 years, its easy to assume that everyone will understand the jargon you use. This only limits the audience the issue will reach. While a clearly described bug that assumes you are communicating to someone very new to the project will take us somewhere.
It is not rocket science, If someone doesn't understand what you are saying, they wont be able to make any attempts. With that said If the issue can not be understood by new comers, that is a barrier of entry.
Let me use an example :
This bug is very understandable to an experienced contributor but has too much jargon for someone new. Bear in mind, am not blaming the author, am just using this as an example. The author doesn't even detail steps for reproducing it.
The first important thing we should ensure in triaging is making sure such authors edit their issue details. With Emphasis on clear explanation If possible avoiding jargon that assumes readers are experts. These very assumptions convince authors that they do not need to show steps of replication because they think duh! everyone has to get it.
Some Pointers to solution — If possible
Bugs that have some not necessarily too much details on how to fix usually receive good response.
Take this bug for example. It is bpo-36782 authored by Paul Ganssle:
The author of this issue describes the issue assuming a beginner in mind and also goes a step further to point to relevant ways of fixing, necessary docs etc.
I have personally worked on many issues with pointers in the past especially in the beginning. If you look at the trend of especially my first PRs, you will see they were detailed and a bit hinted.
My suggestion here is that the bugs labeled as “newcomer friendly” as suggested by Mariatta should have a format close to this. Most new comers are looking for tasks they can understand and ones where they can have a starting point. It can be anything an example pointers to a similar PR, which file/function/module to edit etc.
Do not over hint unless the contributor asks because you need to leave room for something he/she can try on their own to feel a sense of achievement.
Also, let us have the discipline to close PRs from experienced contributors who will solve these issues tagged “newcomer friendly”. Victor Stinner did it for for me on one of my first PRs where I had claimed the bug and invested time on it then someone opened a PR on it. He closed the PR which was a good signal to anyone who was in my position then.
Decision making
If possible, let us always come to a consensus on bugs. I know this we will never ensure 100% because some things will have to take time to agree on but we can do this for most simple issues.
Due to bikeshedding, people debate things and never come to a consensus on even the smallest things. If we can reduce these tendencies for easy things by deciding quickly, we will give room to contributors resolving simple issues very fast. I also don't know why simple things get the most arguments though :)
Take this simple issue for example :
This very easy issue has been blocked am sure majorly because of lack of consensus since 2013. Am sure every new contributor looks it and goes, there is no need fixing something in the middle of an argument.
Fix Post PR barriers too
Another thing that causes most blockers and discouragement is un-reviewed PRs for especially first time PR authors. Seriously for me right now, I would understand when my PR takes months before getting a review.
To a new contributor, it is discouraging. Bear in mind even the number of open PRs on the project itself can give you some vibes of un-reviewed PR tendencies on the project.
Therefore, like Mariatta pointed out, we need more efforts in PR review too because also encouraging new contributors whose PRs we cant review is not an effective move.
To be honest, I don't know the most effective way to solve this because I mean we are all volunteers and cant guarantee making the commitment to review every PR. But this is something the core team can try to prioritize for sometime until we gain stability in regards to response on open pull requests.
Conclusion
I think, many people have pointed out 1:1 mentor-ship and much as its the most effective, it is not very feasible as mentees are so many. I believe we can do some improvements in how issues are triaged/managed and prioritizing code review to attract more and new contributors.
I welcome some questions from new contributors.
