Yifan Ren from the University of Waterloo provides this overview of his UCOSP experience:
I Participated in the BB10 PhoneGap team and was working on porting native plugins for BlackBerry10. I had an enjoyable and rewarding time working on the project, and experienced real-world software engineering practices and open source collaboration.
One thing I really appreciate about the BB10 PhoneGap project is its tasks. It has a list of independent tasks, and each one requests to build a complete plugin project of a useful feature, for example, zip file extraction and compression, barcode scanner, and system dialog. We had a chance to select one that interested us most, and would deal with the whole project, including configuration, source code, build, documentation and tests.
Once I was working on a feature called Applink. It gets app id from the Distimo server and shows that app in the blackberry Appworld. I figured out that its implementation needs http requests and http header settings, and I had just learned these early that week in a university course. At that moment, I felt strongly that this project was a great opportunity to apply my knowledge and skills learned in class to the real-life.
My second task was to build the system dialog plugin, which allows users to prompt global dialogs with buttons from their applications. Thanks to the handy templates and detailed documents, the starting steps were quite easy, while the rest of the work was a little bit challenging but also interesting.
When I was working on this plugin, I was introduced to the Qt library and its signals & slots mechanism of objects communication. I found that to be extremely useful and planed to import that library to my personal project. Moreover, I did learn a lot about fundamental aspects of projects building, such as project structure, configuration, Makefile, and documentation.
Help is always available. We had weekly team meeting to report our process and ask questions. Tim was also available and helpful during the rest of the time. I often received timely feedback and really useful suggestions.
At the final words I can say that working on the BB10 PhoneGap plugins and participate in the UCOSP was a big step for me. Not just for the fact that I developed practical skills and got a deeper understanding of the real-world projects; I also gained open source experience and made contribution to the community. I certainly enjoy working in the team with these awesome people, and would strongly recommend computer science students who wish to get involved themselves and gain open source expensive to apply for UCSOP and contribute!
Faraz Sherwani from the University of Waterloo shares his thoughts on the UCOSP program this term.
Why you may want to UCOSP
- Meet, work with and be mentored by some really smart people in your field.
- Learn a new language, or set of tools that a particular project uses, but that you are not too familiar or experienced with.
- Learn the details of a particular source control workflow that you may not have used in the past.
- Take a course that is altogether different from the Computer Science or Software Engineering courses you have taken or will take.
- Improve your coding style, habits and the general quality of the code you create.
- Code sprint (more below)
Why you may NOT want to UCOSP
- You do not want to or cannot handle doing some work (coding, designing, or discussing etc.) for a course, every week. 8-10 hours of work a week is generally expected for UCOSP.
- You have some course requirements for your major that you need to fulfill but that UCOSP doesn’t qualify for (At the University of Waterloo where I study, UCOSP counts as an elective, not a CS course). Check with your faculty for details on this.
I’m just going to write about what the UCOSP experience was like for me, and hopefully this will help someone who wants to know more about what the program is like.
Getting into UCOSP
I first heard about UCOSP, when I got an email from the head of the CS department at the University of Waterloo, suggesting that I apply. I was told it was a competitive program, where you worked on an open-source project for a course credit. As I read more about it and the projects available this term, it sounded like a great opportunity. I had put effort into my application letter, but didn’t think I would actually get in, so it was quite a pleasant surprise when I did.
Selecting my Project
After getting accepted into the program, in picking a project, I felt I had two options: to pick one for which I was familiar with the language and/or the topic and not have to put in as much effort into the course, or the opposite. I chose the latter, because having to use a particular language or toolset is probably the best way to force yourself to learn more about it, and this was part of the reason why I wanted to join UCOSP. The project I chose was Freeseer, which is written completely in Python; a language I had no previous experience with. There are obviously other criteria upon which you can base your selection, but in my opinion, this is one of the important ones. (You actually give a priority to each of the projects available, and then UCOSP tries to accommodate your preferences in the project they assign you to, but I got the project I had highest on my list so this wasn’t an issue)
I spent about a week before classes started (which is when your UCOSP work starts), learning what I could about Python and Freeseer. I read up on how Python differs from other languages I already knew, and the conventions and coding style it uses. The mentors for Freeseer had emailed us on how to get acquainted with the project. They sent us links for videos that explained what the app was about, and some checklists on things we would have to do to setup our development environment for the project, as well a project proposal template and some other useful stuff.
The mentors don’t expect too much from you in the first week. They had told us that they knew that setting up the development environment would take some time, but that we should try to get some tiny piece of code merged into the main branch, since this is what most people struggle with in the beginning. They also said that people who merge early, tend to get more work done over the term (and therefore a better grade), because they know how the workflow works and they’re not dreading the hassle of trying to merge. I had some issues with setting up my environment but managed to get something merged in the first week and was feeling a lot more comfortable with the project.
The code sprint is probably the best part about UCOSP. The location differs from term to term, but for our term, we had been told that we would be flown out to Facebook headquarters in California, which was pretty exciting for all of us. You can imagine my disappointment then, when the location was changed to Mozilla offices in Toronto, due to scheduling issues. I won’t go into the details about the scheduling issues because it doesn’t matter too much, but despite my disappointment about the location change, the code sprint was a great experience. I got to meet the other students on my project team, as well as the mentors (the one’s who could make it), and a lot of great people from the other groups. As I said earlier, UCOSP is pretty competitive, so all the people you meet are probably going to be a lot like you, because they’ll all have the same (or a similar) major as yours and will all be from the top of their class. Everyone was great, and I found a bunch of people who I shared interests with. Everyone had rooms on the same floor in the same hotel, and would go out in bunches to explore the city. In the mornings, we were to show up bright and early to the sprint location, where each team/project had their own giant table on which to set up their laptops and work. All in all, I would say that the code sprint itself made the whole UCOSP experience worth it. On top of that I enjoyed the work, but I would have done it just for the code sprint, even if I didn’t like the rest of it.
I’m not sure if this part differs from project to project, but in my case, we were told to come up with a proposal for what we wanted to work on for the term, why that work was a good idea, how we would do it, as well as a schedule for how long each component would take. Most of this was to be done near the beginning of the term, but certain things like schedule and implementation details would have to be added/modified as time went on. I tried to find a balance between not proposing enough work, and proposing more work than I would have time for. I wound up being ahead of schedule towards the end of the term and worked on some minor tasks for the remainder of my time but this is probably better than being behind schedule and scrambling to get the rest of your work done.
I really enjoyed UCOSP; it was a great opportunity, and I’m glad I chose to do it. If you’re not sure if UCOSP is for you, hopefully this helped.
Yanjia Xin from the University of Waterloo summarizes her UCOSP experience:
Now you made it into UCOSP! Congratulations! If you’re nervous about what is going to happen, don’t worry, it will pass. You will meet a lot of new people just like you and as time goes by, everything will become easier.
One thing to get started is to poking around the code base and get familiar with the tools you are going to use. That is to say, be prepared. Once you are prepared, there is nothing left to fear. Once you pick a project to work on, get some time to understand your situation before making any changes. Make a plan, and talk to your mentor about it so that you will be working towards the right direction.
Believe it or not, I often underestimate the time I need to finish a week’s job, especially during exam period. If you’re one of those super-organized people, this tip will be easy for you. The rest of us, however, need to develop a system for keeping track of meetings, appointments, assignments, and projects. Get an organizer or planner and keep on top of all your work. Schedule some concrete time each week to do your work and don’t wait till the end. You will never know what will come up to block your progress. And as you look ahead, set goals for yourself — and then strive to achieve them.
Take some notes
Take notes, and you’ll thank yourself later. If you’re a whiz with your handheld, jot notes electronically. Otherwise, invest in a small notebook that you can stick in your pocket and pull out when any idea comes up. This helps extremely when you allocate a small chunk of time for planning, and would like to pick up where you have left off later.
Ask for help
One of the most important thing I learned from UCOSP is asking for help. Don’t hesitate to ask questions when you are stuck. Mentors are humans, and extremely helpful humans. Remember, there’s no such thing as a dumb question. All right, that’s a lie. But after I struggled for days tracking a small bug which takes my mentor one minute to point out, I realized the dumbest thing that can happen is to waste time blocking yourself from making progress.
Think for the future
Another important skill I learned is to write clear documentation. This is very useful in real industry. If you’re stuck on the documentation writing, and aren’t sure how to actually write it, this is my mentor’s ultimate tip to get started: pick up a rubber duck or find someone and explain what you’re doing to them, explain it a few times, then write that down. A good documentation should be fully self-descriptive, allowing someone down the road to read through it and know exactly what you’re doing, why, and how, without having to dive into the code.
That’s pretty much it! To sum up, UCOSP is awesome! I really had a enjoyable time working on Review Board team. It was not so easy to get started, but once you get used to it, you will start to have fun. To me, it was a rewarding experience and I would highly recommend getting involved in UCOSP to anyone want to contribute. Enjoy!