Polishing the Student Experience

After every semester of UCOSP or GSoC, the Review Board team has a post-mortem.  The post-mortem is an opportunity for students to give us mentors some feedback on:

  1. What worked and what didn’t work
  2. What we should do more of, and what we should do less of
  3. What we need, and what we can do without
  4. What things we should provide, and what unnecessary things we can trim back

Here’s some of the things we learned last semester:

We’ve got some decent set up documentation

The instructions for setting up the development environment are well written – students were able to get set up really quickly, and hit the ground running.

Git is a major stumbling block for students

Students are coming at us with varying levels of knowledge regarding version control systems – let alone distributed version control systems.  We really need to make sure they have a solid foundation in Git, or else it’ll bite them later on in the semester when their trees get more complicated.

So it’s not good enough to just show them how to clone a repository, make some changes, and commit them.  Students need to know how to recover from easy mistakes.  They need to know how to think about how their branches relate, what a tracking branch is, and what rebase-ing does.

They need to know how to use Github to set up a fork, and why that’s useful.  They need to know tricks like stashing changes,

We should probably be more visual, and can probably help this by introducing gitx / gitk earlier on, to make it easier for students to understand the relationship between their branches.

And then, on top of all of this, we need to explain how Review Board developers are expected to use Git, and how post-review works in tandem with Git.

On Editors

Some students are coming at us having only used full-blown IDEs to do development.  It might be worth-while to try to help the student set up their IDE to hack on Review Board, as opposed to forcing a student to adopt a foreign editor along with a foreign codebase.


Distributed development hinges on communication.  IRC is a very important tool in this arsenal, and we cannot assume that students are familiar with it right off the bat.  We need to be able to get students up and running on IRC quickly.

We need to be strict on posting status reports

There were a few instances last semester where status reports were posted after a meeting had started.  This is no good, because then we have to waste time at the beginning of the meeting getting caught up on everyone’s progress, as opposed to immediately diving into blockers.

We started getting more strict on that in the second half of the semester, and we’re going to be quite vigilant from here on in.

The blog is good for some things, but we might want to invest in a Wiki

Students have expressed that the blog is uncomfortable and clumsy for things like writing development notes, and for keeping track of progress on things.  Something like a Wiki might be better suited for such things.  We use Google Code to host the Review Board issue tracker – we might want to investigate giving our students access to the built-in Wiki.

Students need examples of good meeting minutes and status reports

We need to show students acceptable examples of both minutes and status reports, so that they have a target to aim for.

We need to map out the layers of Review Board

Review Board is a pile of technologies:  Python, Django, Djblets, jQuery, HTML and CSS.  We need to map out for students how these technologies are used, and how they relate to one another.  We cannot assume that our students are proficient in any of these technologies.  We cannot assume that they know what a web framework is.  We cannot assume that they know how server side software generally operates.

Students are eager for review feedback, and we can’t let it slide

This has been a problem for a few semesters now, but sometimes review requests pile up, and the reviewers lose track of them.  We need to make sure students are periodically reminding us that they’re blocked on particular review requests.  They cannot be shy about this.

Who knows, maybe a student will automate a reminder system as part of Review Board itself.

So that’s the wisdom that we garnered from last semester’s students.  Thanks for the review!


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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