I’m Natasha Dalal, A 4th year student at the University of Toronto. I’m working on Review Board as part of the UCOSP program. While I’m still in the starting stages of my work on Review Board, my experiences thus far have been incredibly positive.
We started off the semester by setting up our development environments and fixing some “easy fix” bugs listed on the review board bug tracker site. This was our entry point into the review board code-base. Setting up the development environment proved to be a bit trickier than I had expected, mostly because of dependency issues. However, there was a wealth of information available in the documentation section of the review board website, and the mentors were really helpful on IRC. After trying and failing to set-up my environment locally, I ended up setting it up using a virtual environment that one of the mentors had set up for us. This came with its own set of bugs and problems, but again, the mentors came to the rescue and were super responsive and available to help troubleshoot any issues as and when I faced them.
About 3 weeks in, the UCOSP students (5 of us) from across Canada, and all the mentors met in person for a 2 and a half day code-sprint at the Mozilla office in Toronto. It was instantly apparent, that we were the best team there (Biased, me? Not at all.) But seriously, the code sprint was a wonderful experience. We were in a room full of incredibly talented and motivated people working on some really interesting and diverse projects. Meeting the review board team in person, and being able to put a face to the IRC nicknames was awesome! Experiencing first hand how excited everyone was about Review Board was even more awesome! At the sprint, we got a chance to get to know each other a bit better, as well as a chance to learn more about the architecture and structure of Review Board. That weekend was a milestone for me, because I made my first ever open source commit, and even though it was just a tiny CSS change, it felt really good. By the end of the weekend, every student on the Review Board team, had successfully submitted their first patch to Review Board and earned their very own Review Board t-shirts for their accomplishments.
At the sprint, I discovered some useful tools to help me navigate my way around the project. While I started out with a stubborn desire to strictly use vim for all my code-editing needs, I quickly realized that I am nowhere near being the vim master I dream of being, and so, in the interest of time, I decided to switch to using Sublime. While I definitely haven’t explored the full potentials of Sublime yet, I did find some things in particular to be very handy. For one, I like that you can “open folders”, which gives you a side-bar in sublime through which to navigate through a collapsible tree structure of the sub-folders and files of the given folder. There is also a powerful search function across all files in the open folder. The code-completion and syntax highlighting are also pretty useful. Additionally, if you know the name (or part of it) of the file you want to jump to, the Ctrl-P shortcut lets you quickly search for and open that file from within your project. There are also a ton of plug-ins available to help customize your sublime experience.
As someone who has never really programmed in python before, I also had the joys of learning about pdb, which is the python command-line debugger. It was incredibly easy to use, and turned out to be very helpful as I attempted to debug something (that wasn’t actually a bug) over the weekend. Setting a break-point in pdb is as easy as adding the line: “import pdb; pdb.set_trace()” to the part of your code that you want to debug. This then allows you to use the debug prompt in your shell to actually debug things. There is a blog post about this on the review board blogs at https://reviewboardstudents.wordpress.com/2012/01/22/the-python-debugger-pdb/.
Towards the end of day 2 of the sprint, we all sat down and discussed potential projects for the semester. I believe all of us ended up choosing from an existing list of student project ideas, although we were also given the liberty of coming up with our own. The project I chose was to implement a suggested Reviewers feature, which examines past activity to suggest prospective reviewers to a user posting a review request. I have a post outlining my basic strategy for it on hackpad, which I expect to evolve as I make progress on it. Here is a link to it: https://reviewboard.hackpad.com/Suggested-Reviewers-Feature-QI4YGdzLEWy .
So far, I have explored some of the areas of the code that I will need to look at, and have implemented a very simplistic function to work on the back end. As mentioned before, my experience with python and django is limited, but I have found it to be extremely powerful, easy, and convenient to work with. I find the organization of django projects and it’s use of MVC very appealing and easy to work with.
Taking part in UCOSP is one of the best decisions I have made for myself in a while. This is either a testament to how great I think the program is, or to how terrible I am at decision making, and I’m choosing to go with the former 🙂 . In a sea of mundane course-work, my review board project is what’s keeping me afloat. That was a little dramatic, I’m actually enjoying most of my classes, but this one slightly more than the others, and I expect the practical skills I gain from it to be exceedingly rewarding in the long run. On that note, I am grateful for the existence of UCOSP and for being able to participate in it. I am also really happy that I chose to work on review board, and hope to keep contributing to it after my UCOSP term is complete. The Review Board team is wonderful, helpful, and extremely dedicated, which makes them a pleasure to work with. I’m excited to make more progress on my project, and hope that the rest of the semester continues to go as smoothly as it began.