Yesterday I went live with ScalaNirvana, a website that up until now, only existed in my imagination. As I picked my brain, the idea of documenting my so-called climb towards Scala Contributor status, appeared to me to be a means to fleshing out an article that was appealing, and helpful, to others. This article, may be seen as a small toehold in that climb.
Documented below are baby steps, steps that I believe are part of a steep, yet fulfilling, learning curve. The idea is to scale this curve and become a Scala Contributor. For now, if you are like me, someone that wants to put a stake to the ground in their endeavor to get to know Scala up close, simply working your way through this article, can ease your own journey a little, whether that journey is about becoming a Scala contributor or not.
Time will tell. For now, lets get started with the Scala Contributor Level Agreement, our entry point.
Back in June 7th, 2017, right after I signed the Scala CLA. EPFL sent me an email with the instruction that reads as follows: “If you have already sent a pull request please add a comment to the pull request saying you did sign the CLA.”
My understanding of this is: “Fork scala/scala from my github account. Several trials and tribulations later, if I fixed a bug in the Scala code base, I would send out a pull request, with a comment added to the pull request, telling EPFL I had signed the CLA”
Fixing a bug is the goal. I am not there yet.
After some head scratching and hair pulling, I found the Scala Contributors channel. This looked like the place with the potential to get me started. Whether it was about implementing my broad, daunting vision of becoming a contributor or not, I was curious to find out what challenges lay immediately ahead, what low-hanging fruit was ripe for the picking. Indeed, scala/contributors is “where people discuss scala internals and open-source work with contributors.”
I ran into Jason Saugg of Lightbend, rather fairly quickly after I posed the following question to all present, that question being: “I had signed the SCA. What is next? What is the easiest way to start contributing?” Jason wanted to know where my interests and experience lay, before coming back to me with an answer, which was: “There are a variety of ways to contribute“, and in order to “get used to the contribution process, contributing an improvement to the documentation, or fixing a small bug is a good way to start”
Whether you are an experienced Scala developer, a wannabe Scala developer coming in from Java or Python, or someone migrating from a non-programming area, improvements in documentation may be the easiest territory to navigate. According to Jason, if we want to start contributing, documentation is where one can quickly figure out the amount of work it requires.
Based on my interactions with Ichoran, I learned that a bug, however small, and seemingly simple, can present one with unexpected challenges, derailing the learning process, at least for the near term.
On the other hand, “Fixing a small bug can be a better learning process”. The thing is, once we forked the code into a local environment, we jump into iterative code change and compile cycles in a bid to fix the bug. Tests are written and failing tests are made to pass. Hopefully, in a reasonable amount of time, the bug is fixed, a pull request is initiated and with more luck, our bug fix may be accepted into scala/scala, completing a fulfilling learning process.