Who’s Doing What (Winter 2012 Term)

So each student on the team has a few extra responsibilities this semester.  In particular, a student will be responsible each week for collecting / hounding down status reports and posting them on this blog before the weekly IRC meeting.  Another student will be responsible each week for taking the meeting transcripts and turning them into nice, summarized posts which will also be posted here.

Here is an example of a status report post – notice how short and punchy each status report is.  They get right to the point:  Status, Next Steps, Roadblocks.  Point form is fine.  Again, these should be collected and posted, and then read by the team before the IRC meeting.  This way, we’re all more or less on the same page when the meeting begins.

And here is an example of an IRC log summary.  Again, point form is fine.

So, here’s the schedule – please note that it might be subject to change, so check back often.

January 28th – status reports: Jim, minutes: Curtis
UCOSP Blog Post (Due January 30th) - Anthony

February 4th – status reports: Wei Lu, minutes: Jim
February 11th – status reports: David, minutes: Wei Lu

UCOSP Blog Post (Due February 13th) – Curtis

February 18th – status reports: Wilson, minutes: David
February 25th – status reports: Steven,  minutes: Wilson

UCOSP Blog Post (Due February 27th) – Jim

March 3rd – status reports: Anthony, minutes: Steven,
March 10th – status reports: Yazan, minutes: Anthony

UCOSP Blog Post (Due March 12th) – Wei Lu

March 17th – status reports: Curtis, minutes: Yazan
March 24th – status reports: Jim, minutes: Curtis

UCOSP Blog Post (Due March 26th) – Steven

March 31st – status reports: Wei Lu, minutes: Wilson
April 7th – status reports: Anthony, minutes: Steven

UCOSP Blog Post (Due April 9th) – Wilson

Post-mortem (date TBA) – notes: Mike

Team:  I highly recommend bookmarking this post, and marking your days down in a calendar somewhere.

IRC Who’s Who Guide (UCOSP Winter 2011-2012)

UCOSP Mentors:

• ChipX86: Christian Hammond
• purple_cow: David Trowbridge
• m_conley: Mike Conley

UCOSP Students:

• happyface: Dave Druska
• medanat: Yazan Medanat
• smacleod: Steven MacLeod
• jimrrchen: Ruirong Chen (aka Jim)
• ammok: Anthony Mok
• CurtisM: Curtis Muller
• weilul: Wei Lu Liu (aka Willer)
• H20_: Wilson Yeung

Cool Guys (non-UCOSP Winter 2011-2012):

• mbait
• matthiaskrgr
• vladikoff

Bots:

• CIA-71: cia.vc bot

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.

IRC

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!

UCOSP Student Post

Thanks to UCOSP, this school term has been a very busy and exciting one, where I get to work with some talented students and mentors on the ReviewBoard project. As the term draws to a close, I have learned many aspects of working on an open source project that has a wide user spectrum.  I learned that effective communication and cooperation is vital to the successful progression of a project. Every week, we hold a one-hour online group meeting through IRC to ask and answer questions, and exchange thoughts and ideas. Moreover, the UCOSP blog provides a convenient facility to exchange developer tips and tricks, project status and other important information. Students and mentors also communicate actively via e-mails.

Over the term, I have been working on adding the features of uploading, storing and displaying per-diff file attachments. Up to this point, the UI, database model and business logic changes for storing and displaying the attachments have been implemented. The remaining work is modifying the Web API and the PostReview tool to enable the features.

Although this term has been a great learning experience, I’ve realized that it would have been even more rewarding if I had done more thorough preparation before the term started. This is exactly what I would suggest to new UCOSP students. One or two weeks before the first UCOSP orientation meeting, learn as much as you can about the project on your own, including the programming language, the source control system, and any related tools. Then, you can take hard questions to the orientation meeting and get the most out of the opportunity to have the talented mentors instruct you face-to-face. By doing this, you will be taking a big first step towards your success in the term!

Who is doing what for Fall 2011?

So each student on the team has a few extra responsibilities this semester.  In particular, a student will be responsible each week for collecting / hounding down status reports and posting them on this blog before the weekly IRC meeting.  Another student will be responsible each week for taking the meeting transcripts and turning them into nice, summarized posts which will also be posted here.

Here is an example of a status report post – notice how short and punchy each status report is.  They get right to the point:  Status, Next Steps, Roadblocks.  Point form is fine.  Again, these should be collected and posted, and then read by the team before the IRC meeting.  This way, we’re all more or less on the same page when the meeting begins.

And here is an example of an IRC log summary.  Again, point form is fine.

So, here’s the schedule – please note that it might be subject to change, so check back often.

September 18th – minutes: Yazan, status reports: Waleed
September 25th – minutes: Waleed, status reports: Jacob

UCOSP Blog Post (sent to reviewboard-ucosp before October 2nd):  Waleed

October 2nd – minutes: Jacob, status reports: David
October 9th – minutes: David, status reports: Yazan

UCOSP Blog Post (sent to reviewboard-ucosp before October 16th):  David

October 16th – minutes: Yazan, status reports: Waleed
October 23rd – minutes: Waleed, status reports: Jacob

UCOSP Blog Post (sent to reviewboard-ucosp before October 30th):  Yazan

October 30th – minutes: Jacob, status reports: David
November 6th – minutes: David, status reports: Yazan

UCOSP Blog Post (sent to reviewboard-ucosp before November 13th): Jacob

November 13th – minutes: Yazan, status reports: Waleed
November 20th – minutes: Waleed, status reports: Jacob
November 27th – minutes: Jacob, status reports: David
December 4th – minutes: David, status reports: Yazan
Post mortem date TBD – minutes / status reports:  Mike

Team:  I highly recommend bookmarking this post, and marking your days down in a calendar somewhere.

Who is doing what for Winter 2011?

So each student on the team has a few extra responsibilities this semester.  In particular, a student will be responsible each week for collecting / hounding down status reports and posting them on this blog before the weekly IRC meeting.  Another student will be responsible each week for taking the meeting transcripts and turning them into nice, summarized posts which will also be posted here.

Here is an example of a status report post – notice how short and punchy each status report is.  They get right to the point:  Status, Next Steps, Roadblocks.  Point form is fine.  Again, these should be collected and posted, and then read by the team before the IRC meeting.  This way, we’re all more or less on the same page when the meeting begins.

And here is an example of an IRC log summary.  Again, point form is fine.

So, here’s the schedule:

• Jan 16:  minutes: Teresa
• Jan 23:  end-of-code-sprint status reports:  Steven
• Jan 30:  status reports: Mengyun, minutes: Crystal
• Feb 4:  UCOSP Blog post:  Mengyun
• Feb 6:  status reports: Crystal, minutes: Kahlil
• Feb 13:  status reports: Kahlil, minutes: Mark
• Feb 18: UCOSP Blog post: Steven
• Feb 20:  status reports: Mark, minutes: Teresa
• Feb 27:  status reports: Teresa, minutes: Steven
• Mar 4: UCOSP Blog post: Mark
• Mar 6:  status reports: Steven, minutes: Mengyun
• Mar 13:  status reports: Mengyun, minutes: Crystal
• Mar 18: UCOSP Blog post: Teresa
• Mar 20:  status reports: Crystal, minutes: Kahlil
• Mar 27:  status reports: Kahlil, minutes: Mark
• Apr 1: UCOSP Blog post: Crystal
• Apr 3:  status reports: Mark, minutes: Teresa
• Apr 8: UCOSP Blog post: Kahlil
• Screencast blog post:  Mengyun
• Post-mortem (date TBD) minutes:  Steven

Team:  I highly recommend bookmarking this post, and marking your days down in a calendar somewhere.

So, where are we?

If you’ve been following this blog, you’ll know that the team has been working very hard on their projects.  But I’ll bet those status reports can be a bit cryptic sometimes.

So here’s my take on where we are so far, in no particular order:

1. Hongbin has been working on an extension that will allow communication between Review Board and various bug-trackers.  Currently, his extension listens for events on Review Board (such as publishing a review request, publishing a review), and then alerts the appropriate issue/bug in the bug-tracker by posting a comment with a link to the review request.  Hongbin’s extension currently only works with Google Code projects, but will eventually be extended to other bug-trackers as well (Bugzilla, Github’s issue tracker, etc).
2. Laila has put together a new version of the Windows Review Board installer.  The installer is responsible for making sure a Windows machine has everything it needs in order to get an instance of Review Board up and running.  Laila is also working on a project that will allow review requests to have files attached to them.
3. Lindsey and Brendan have been putting together an impressive suite of client tools to interact with the new Review Board API.  The monolithic “post-review” script will, I believe, be eventually modified to use these scripts.  The scripts are also designed to be easily imported, so that developers can write their own tools to interact with Review Board.
4. Lianne has been working on an extension that will give Review Board WebHook notification abilities.  This means that, when various events happen on Review Board, the extension can send a request to a remote server to trigger another action.  Example:  when a review request has been marked as submitted, the Webhook might signal a script that publishes a notification to Twitter, or to an IRC bot, or to an RSS feed, etc.
5. Kevin has completed his “collapsible-reviews” project: for review requests with a long series of reviews/revisions, we can save on vertical screen real-estate by automatically collapsing the reviews that have been read.  Kevin has also implemented a one-click Ship-It function, which makes easy reviews even easier.  Kevin is now working on the designs for a new user profile page for Review Board.

I hope I didn’t forget anything.  Comment (or update this post) if I have.  Keep up the good work, team!

Who is doing what for Fall 2010?

So each student on the team has a few extra responsibilities this semester.  In particular, a student will be responsible each week for collecting status reports and posting them on this blog.  Another student will be responsible each week for taking the meeting transcripts and turning them into nice, summarized posts which will also be posted here.

Here is an example of a status report post – notice how short and punchy each status report is.  They get right to the point:  Status, Next Steps, Roadblocks.  Point form is fine.  These should be collected and posted, and then read by the team before the IRC meeting.  This way, we’re all more or less on the same page when the meeting begins.

And here is an example of an IRC log summary.  Again, point form is fine.  We’ve already had two meetings, so two students will need to go back and post those summaries up over the next few days or so.

Anyhow, without further ado, here’s the schedule:

• Sept 19:  minutes: Brendan
• Sept 26:  minutes: Laila
• Oct 3:  end-of-code-sprint status reports: Kevin
• Oct 10: status reports:  Lianne, minutes: Hongbin
• Oct 17: status reports:  Hongbin, minutes: Lindsey
• Oct 24: status reports:  Lindsey, minutes: Brendan
• Oct 31: status reports:  Brendan, minutes: Laila
• Nov 7:  status reports:  Laila, minutes: Kevin
• Nov 14: status reports:  Kevin, minutes: Lianne
• Nov 21: status reports:  Lianne, minutes: Hongbin
• Nov 28: status reports:  Hongbin, minutes: Lindsey
• Dec 5: status reports:  Mike, minutes: Mike

Team:  I highly recommend bookmarking this post, and marking your days down in a calendar somewhere.

Starting up the Review Board Student Blog

So this is the blog where we, the students working on Review Board, can post our meeting minutes, status reports, and various struggles/musings/discoveries, as we tackle Review Board development.

More soon.  Stay tuned.