How I got more involved in open source
At the beginning of the year, I made up my mind about contributing more to open source. Following is a write-up on my experiences so far.
Starting on open source is easy
Just pick any project on GitHub and you can just dive into the issue list to see what is missing. However, to get the most out of the time you invest you need to figure out what you want to get out of it. For me, the primary goal is to code more. Second, I really wanted to learn something new, so I tried to look for projects in a language that I had no experience with.
O365CLI
There is no way I missed out on some of the noise around the O365 CLI. If you follow the PnP Webcast or Waldek on any social, you must have seen the updates. Born out of necessity, there is allure in building on something cross-platform. Clear guidance on how to start contributing made it easy to start participating.
During the last weeks of December, I installed and forked the project and just started to play around with the code. Without any experience on a cross-platform or testing approach, I did cheat a bit. I did pick the easiest command I could find. Even then it took me way more time than planned. So pick an open source project you like and get started!
Learning and adapting
Once the first command was done and I got my first PR approved it did trigger a sort of addicting spark. So, I ended up signing on for another one immediately. For this command, I divided my approach into a few steps. This made it a bit easier to keep track:
- Bootstrap the command
- Write-out documentation
- Tests implementation
- Implement the tests
I did try to write the tests first, but as I didn’t have too much test experience that didn’t work for me. After doing a few commands it became easier and easier as you get to know the project structure. Chatting up a bit on Gitter, pinging some other contributors (thanks Waldek and Velin Georgiev) it felt good enough to start suggesting other commands and improvements.
I did change up the steps a bit:
- Spend a few minutes on the issue tracker to comment or add new commands
- Propose specifications for new commands
- Create and bootstrap the command
- Tests implementation
- Writing actual code
- Finalize documentation
Planning your open source work
To keep the flow going I try to block between one and two hours a week to work on it. It turns out that if I do not block at least one hour I do not get into the flow. And if I ever forget to work on it you do get some reminders that you already committed to work on an issue. The hardest part once I am in the zone is to stop working after an hour. Once a new command is finished, I want to start a new one immediately. However, if I do that, I lose interest in the long run. By not finishing it right away, I deny myself closure. This keeps bugging me so that I tend to come back and finish it some other time.
The cool thing about the steps is that I can spend a few minutes a week to just do the first two things, then select one command and commit to getting that through as quick as possible. For the CLI there is almost a weekly cycle to get new things out. That always triggers me to try and get a command or PR out once a week.
Learning is key
My goal is to learn some new things, so I do not know how long the same project stays interesting. So far, I have learned something almost every week for the past six months. But as there are over 50 repositories for PnP there are enough projects to learn something new from. I am sure there is more than enough left to learn about!