Student blog post: Niklas @ Reviewboard

Hey, I’m Niklas, a third-year Computing student from Imperial College London, and on one of the group of students working on ReviewBoard this winter as part of the Open source, project-based, collaborative university curriculum organized by Facebook.

The goal of this industry-sponsored, cross-university project is to allow Computing students from around the world to make collaboration in a widely used open-source project part of their degree. While in a normal Computing course you would usually theory, work on practice problems set by academics, and write an exam in the end, this course is different: You work on a real-world product, probably used by thousands of individuals or companies.

The course started off as a 2-day Hackathon at Facebook’s office in Palo Alto in mid-January, and continues to run over the next few months, according to each student’s university timetable.

While the course does not count as a for-credit module at my uni and I’m therfore participating for the fun and the experience, I think it is a great idea, and I find that something like this should be part of every Computing degree.

My part in Reviewboard this Winter

I had used Reviewboard before, and I found it quite good, but not perfect, which is why I picked it as one of my favorite projects to work on.

The starting-off hackathon was great as both a free-time activity and a learning experience.

I met Mike, Christian, David and Steven from the ReviewBoard team, and from their experience of ReviewBoard’s deployment in the companies they work for as well as in others, I could get a good insight on what ReviewBoard aims at, what users expect, and what development is focused on.

On the technical side, I could also exchange some experiences about Git workflows, and from our mentors I could learn about what it is like for them to work part-time on an open-source project while also working at companies where a lot of time is spent on writing open-source software.

Getting started

To get into the project, my first contributions were fixing an error that occurs when you try to access properties of a review request that doesn’t exist and [making sure that the “add comment” button is only shown when you are logged in. I also got into how tests are written for ReviewBoard.

What I’m focusing on

When I first tried out ReviewBoard in 2012, I found that some workflows are harder than I expected them to be, especially for small, flexible teams without fixed policies, such as a project group of students or a small open-source team.

I will therefore spend the rest of the term on this: Making ReviewBoard easier for small teams.

What originally annoyed me most is that after rising an issue about some piece of code, I was unable to declare the issue as fixed myself; it always required an additional roundtrip, summoning up the person who originally wrote the code and posted the review request, even for issues that are obviously fixed. So I implemented that comment creators can now fix/drop issues themselves. It took me quite a bit to figure out what the control flow for the fixing of issues was, but in return I now have a better understanding about how ReviewBoard webapi requests are handled.

One thing I would wish for the project to have is a simpler way of testing, especially something I would call “testing primitives”. For testing my change above, I have to control two users at the same time, create a review request, create a file review and create an issue n that file review, and only *then* I can test if what I’m interested in actually works: Closing the issue. The steps before that are mainly preparatory steps, but I still have to execute them quite technically, crafting the webapi calls by hand. I don’t go as far as asking for something like Cucumber, but I would prefer to write these steps with primitives like this instead:

    u1 = give_me_whatever_arbitrary_user()
    u2 = give_me_whatever_arbitrary_user()
    r = make_arbitrary_file_review(user=u1)
    issue = open_some_issue_on(r, user=u2)

    # And now the actual testing code to see if u2 can close the issue themselves

Here, I don’t really care what the contents of the file review or the text of the issue are, I just want *some*, and I would like to get them automatically, without thinking about it, so that I can write tests in a way as easy as above.

Maybe we can set up something like this?

When I done with this, I will have a look on whether I can improve the command line tool that submits code changes, making it a bit easier for the cases I’m especially interested in.

Going on

So far, I’ve enjoyed working on ReviewBoard; if you want to get into contributing to open-source software, it’s a good place to join.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s