In this series of posts I will go over the basics of contributing to Xamarin.Forms. I have 4 posts planned initially: my story, before you open a pull request (PR), opening a PR and after you opened a PR.
In this first post I will tell you a little bit about my background. By sharing my story, you will hopefully recognize some thoughts and feelings that you might have yourself. Also, you will see why it is important to me to enable you and empower you to contribute to Xamarin.Forms.
Contributing to a large project, owned by one of the biggest companies in the world can be rather daunting. Your imposter syndrome will probably tell you that you are not good enough, however do not let that fool you!
I will share with you a bit of my history as a contributor and how that led me to joining Microsoft on the actual Xamarin.Forms team. Ultimately, I hope to empower you to contribute yourself by giving you enough confidence and all the knowledge to get started. Ideally for the Xamarin.Forms project, but I’m happy with every project you might contribute to after reading this. That also means: while this writeup will be specifically about Xamarin.Forms, you might be able to apply some of the things in here to contributing to open source in general.
My Story about Contributing to Forms
Lately I have been talking to several people that express their wish to contribute to Forms. The desire to contribute can have a lot of different motivations: implement something you think is missing from the framework, fixing a bug, simply wanting to do something back for the community, upgrading your skills, etc. In the end, it doesn’t really matter why you want to get started.
For me it was a mix of different things: brushing up my skills and wanting to do something back to the project I have been using for so long. But like a lot of other people I felt that I had nothing to add to such a project. I was (subjectively) good at creating nice apps with the help of Xamarin.Forms, but what could I possibly contribute that the core team couldn’t do better?
F100 Community Sprint
The turning point for me came with an initiative now known as the F100 community sprint.
The issues labeled F100 refer to “death by a 1000 (paper)cuts”. This is an ancient Chinese torturing method which is luckily not at all related to anything Xamarin. The “death by a thousand papercuts” variation refers to a pun in the bureaucratic area where a lot of paper is moved, but only minor progress is made. In our case it is more like a saying. There were – and are – a lot of smaller issues for Forms that in itself are very minor, but add up to a big pain in the behind. They’re all small issues that could (relatively) easily be fixed but the core team doesn’t get around to. With a couple of people from the community we got together and picked up a number of these issues. This way we could make an impact by solving a lot of those annoying little bugs/features that we were all missing.
Being able to share this experience of contributing with a couple of others and being able to ask questions to people I see as peers was the reassurance that I needed to drag me across the line.
Getting to Work
We created a channel on the Xamarin Chat Slack and got to it. If you do not know the Xamarin Chat, this is a Slack instance where people get together from the community, mixed with some Xamarin and Microsoft employees and share tips and experiences.
Together with the Xamarin.Forms team a bunch of these F100 issues were identified and then labeled as such. We went through the list and assigned ourselves to issues that we were able to and wanted to pick up. Because of that interaction in the Slack channel and being able to ask someone (simple) questions really helped. For one, you can see you are not the only one with questions that seem too simple to ask.
Questions that you feel you should already know the answer to and you can never ask the team because you would look stupid. As a (very important) side-note: please never think that. I know you will, I know I did feel that way, but please, if you have a question, big or small, ask us. We’re happy to help you, help us.
It took me a little while to grasp all the concepts of how to get the code base, where I could find what classes and how to actually add value. If you think about it, that is not really that weird. Whenever you step into a new project that has existed for a while, you need some time to look around and get familiar. Although you have been using the framework for quite some time, it’s not expected that you know all the details on the internals.
Contributing the Entry.MaxLines Feature
The feature I chose to implement was the Entry.MaxLength. With this new property on the Entry and Editor control, you can specify a maximum length for the string you can enter.
This feature was pretty straight-forward and therefore easy to implement. Perfect for a first contribution! If you look at the linked PR, there is a lot of feedback though.
That can be quite overwhelming! But just remember, you’re not wrong. The team just has a ton of experience. Because of that, they know what might cause trouble and what might not. Also, your coding style might be a bit different than the style of this project. Just take the feedback and learn from that, isn’t that what it is all about? 🙂
What you also must not forget is that the team very much appreciates your time and efforts. But this does not mean that we just allow anything in without a proper review. Don’t let the feedback get you down though. Just keep at it, you will get it right and we will be thankful.
After this contribution and my initial fear was over, I was hooked. It feels good to be able to do something back for the framework I have been working with (for free!) for so long. It is great to be able to debug and fix any issues that you might have and fix it yourself. As a bonus, you are marked as a contributor and other people benefit from your work as well. You might have seen me writing about Label.MaxLines or Android WebView Zoom or HTML markup in a Label.
The Rest is History
If you have been following me you might know that ultimately I got hired by Microsoft and am now part of the – you’ve guessed it – Xamarin.Forms team! Now, I’m not saying that starting to contribute for Forms or any other repo will have this as a result, but as you can imagine it does help.
By contributing to open-source software I think you show potential employers that you are passionate about what you do. It shows that you are willing to learn and put yourself out there. And if ultimately there is a position opening on the project that you have been contributing to, that is a big advantage.
You already know the code-base, you already know a bit about the team and the team about you. In addition, the team already has seen a little about how you work and what value you deliver.
I have not been told what were the exact reasons to hire me, but I can only imagine that my contributions played a role in the final decision.
Before I end this post, there is a couple of things I’d like to state beforehand as I will get started on the next posts in this series. While I can’t of course speak for all of the team, I do think that we all agree on this, at least I do.
We know you are probably contributing besides your regular work. That make us appreciate your time and effort even more. We are all busy, we have so much to do, but you choose to spend a little of that knowledge and time on our product, that is awesome!
Because of that, we also understand that your available time or priorities might change. If that is the case, no worries! We’re still friends. The only thing I ask is that you let us know. Just a single line comment that you’re unable to finish it is enough. We or someone else know that it is safe to take over and get it done. You’ll still get the credits for the initial work. Communication is everything!
I just wanted to put this out there. The actions on GitHub or otherwise do not always translate well to the fact that we do appreciate every effort.
In this post I have shared with you my first experience with contributing to a large open-source project: Xamarin.Forms. Now that I have even joined the team, I am eager to convince more people of the fact that it is not that scary to contribute to these kinds of projects.
While on this mission, I will try to create some content around this to take away any gaps in your knowledge and any roadblocks that you might encounter. I want to empower you to be able to do more in terms of maturing the framework and by that doing yourself and a lot of others a favor.
If there is anything you’d like to see or that I can help you with, please reach out. Either through here, Twitter, my live streams or e-mail and we will find the best way to get to a solution.
I will update this post and future linked posts so you will be able to find all the content I will create for this in the (near) future.
4 thoughts on “Contributing to Xamarin.Forms: My Story”
A great idea for a blog post. As someone who has often thought about contributing to open source projects but who usually just ends up raising bugs and helping with non-code tasks I look forward to reading the rest of the series.
I hope I can get you across the line 🙂 If there is anything you need, please let me know! Also, raising bugs and non-code tasks; also very valuable so thank you for that!
Thanks for this blog, I’d value a follow on but detailed blog that shows how you contribute, all the steps. I use git, but I don’t know it, so all this PR, branch, merge stuff is a bit intimidating too.
I’d like to contribute towards some plugins (e.g essentials) but I haven’t a clue about the build process, testing, etc.
I heavily use Xamarin.Forms and various Nuget plugins, maybe an insight into how you create or maintain those plugins will help people like me get started.
Thanks again 🙌
That is exactly what I want to do Rob, so stay tuned!
In the meanwhile, maybe you can follow along with my live-streams where I also do some contributing. You can find the archives on YouTube.com/GeraldVersluis and the live streams on twitch.tv/jfversluis.
Thanks for reading!
Comments are closed.