I’m Michelle Chuang, a 4th year Computer Science and Biology student at the University of British Columbia. Like most of the people here, I joined the Review Board team through the UCOSP program after hearing several of my friends speak highly about the program. When I discovered that Review Board was one of the projects available, I became so excited. I just completed a summer internship at Amazon where I had to use Review Board extensively for our code reviews. Getting a chance to contribute to a tool that I had used all summer and impacts so many people was something I couldn’t pass up. In addition, I thought it would be a great chance to strengthen my Python coding skills, learn about the Django framework and gain experience in front-end web development.
At our code sprint in Waterloo, I started by tackling a few “Easy Fix” bugs. The first issue was a report that URLs to invalid files in review request diffs returned a 404 page with an empty respond body instead of a 404 page with an error payload. It was an interesting way to start my exploration through the Review Board code base, as the issue turned out not to be a bug but a result of browsers and certain plugins hiding the payload. However, it gave me an opportunity to dive deep into the areas of the code that handled URL requests. My second issue was a missing 404 for URLs to diff comments from an invalid diff or file. Luckily, this turned out to be a real bug that I could acutally fix and I eventually traced the problem back to an assumption that if the review request was valid, so were the diff and the file. A few new lines of code here and there and I thought I was ready to ship my code. Unfortunately, my bug fix caused a unit text to fail and it took a few hours of further examination to realize that I had discovered a new bug that had been previously hidden by the bug I had fixed. Despite having to fix this new bug, the fix allowed me to learn how the unit tests worked and gave me an immense appreciation for the sheer size and complexity of the Review Board code base.
My main project is with Pluggable UIs, which is an extremely useful addition to Review Board’s functionality. Originally, it was decided that I would work on PDF reviewing UI but was redirected towards image reviewing UI after some workload analysis. Consequently, I haven’t been able to make as much progress in my project as I would have liked, but looked into several resources for image reviewing. My model for image reviews is Github, which utilizes four different ways to view and compare images: 2-Up, Swipe, Onion Skin and Difference. The goal is to have each of these views (or similar views) implemented by the end of the semester
2-Up involves viewing both images side-by-side without any addition bells and whistles, and is particularly useful if the image has changed size. Swipe overlays both images atop one another and allows the user to view portions of the original and new image depending on where the swipe slider is. Onion Skin also overlays both images, but allows the user to change the opacity of the images to fade in and out of original and new images. Lastly, Difference highlights the pixels that are different between the two images by calculating the difference of each pixel per RGB channel.
There are several other ways to represent the changes between images. One such way is using the percentage difference between images. The percentage difference between images (of the same size) can be computed by summing the difference of each pixel per RGB channel (i.e. three differences per pixel), and divided by the total number of components (number of pixels times three), divided by 255 for the number of possible values for each RGB channel. This is also similar to how Github generates their Difference view via RGB channel differences. Alternatively, pixels can just be compared as a whole instead of through each channel individually to generate the percentage of pixels changed and which pixels are changed. With this information, we could display the changes with a bounding box around the area that contains the changes. A problem with this approach though is that if the image is only modified slightly (such as darkened), the change is considered equivalent to if the image was changed completely despite being similar from a human eye’s perspective. Lastly, changes can also be represented using the ΔE* distance metric to calculate the color difference. This approach is comparable to Difference view approach that Github uses and can be used to generate a difference view using shades of grey.
At the end of the semester, UBC requires its UCOSP students to give an oral presentation of their work to the university’s supervisor of UCOSP, where we discuss the project in general, our specific contributions to the project, and what we feel that we learned from the experience. It will be interesting reaching the end of this semester and reflecting on the progress that I’ve made on Review Board. I feel like UCOSP is such a great program for students, even those who have done internships or co-op, since it allows us to continue to work on projects that have a real impact rather than just one-off assignments here and there. I hope to make the most out of this experience, and would love to continue contributing to Review Board after this semester.