Earlier this year, the PrestaShop product team decided to use new leverage to help new contributors participate in the PrestaShop project on GitHub: the ‘good first issue’ label.
But what is it exactly? And how does it work? Below are some questions raised to give it a proper definition and specify its use:
What does this label mean?
People participating in the PrestaShop project do not have the same purpose, they also do not share the same skills. And because all profiles should be able to contribute, the goal is to offer many ways of getting involved.
Among other contribution possibilities, the ‘good first issue’ label allows a smooth onboarding to the PrestaShop open source project on GitHub. Indeed it gets the list of all bugs or improvements estimated with low complexity that do not have any pull request linked to yet. Anyone can pick one and start working on it!
Of course, it won’t avoid unexpected complexity to pop up - PrestaShop’s code hidden talent - but we try our best to sort the most transparent issues out with this label. And you can always ask questions and get help.
Onboarding beginners properly is key; there is a good chance that they will keep on contributing because they will learn the process and then play by the rules.
Who is concerned?
All technical profiles who are not familiar with GitHub, open source, or the PrestaShop project and who are willing to contribute before moving, perhaps, to more complex issues.
Most importantly, this label concerns all people who are eager to get involved in an easy first contribution experience.
Go to the issues tab on the GitHub project here and click on the label in the dedicated banner to have all the good first issues listed. Welcome on board!
What makes a ‘good first issue’?
Here is the touchy part: how to define a first issue when all situations are different and when its solution might bring up extra complications. A few elements are studied to decide whether or not an issue is good for first-timers.
Severity of the bug
In the PrestaShop classification, severity has four levels: trivial, minor, major, and critical. It goes without saying that only the first two levels will be taken into account in this case. So we can ensure you that good first issues are likely to be either trivial or minor bug reports.
In the good first issues list, you will also found small feature requests, display bugs or other improvements that should be pretty easy to code. And this is where our beloved developers intervene, to help estimate as accurately as possible the issue’s degree of complexity.
Usually, an issue is considered ready to be developed once specified. In other words, the expected behavior must be defined in this issue, this is why you will only get issues that contain a clear or detailed functional perimeter.
Having the author of the issue already giving elements of the solution (when he/she has a clue) is much appreciated since it will help you to work on it. It is not required though. But it is a really nice bonus. ;-)
Now you have found an interesting good first issue and would like to work on it? Just create a pull request mentioning the number of the good first issue it fixes to have it reviewed by our teams or the community!
Have another idea to extend the use of this label? Feel free to comment this post, we will be glad to have your feedback!