Category Archives: Administration

Who’s Doing What (Winter 2013 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 at least 24 hours before the first 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:  Current Status, Next Steps, Roadblocks, Questions.  Point form is fine.  Again, these should be collected and posted, and then read by the team 24 hours before the first IRC meeting.  This way, we can answer questions in advance, and we’re all more or less on the same page when the meeting begins.

And here is an example of some meeting minutes.  Again, point form is fine.

We also ask each student to write a post for the blog. Each student will be assigned a week to write a post. Their post should be about what they’re experiencing, what difficulties they’re dealing with, and what they’ve learned. Here is a good example post.

This semester’s scheduling is particularly complex, so I’ve opted to use a Google Calendar. The “agenda” view is particularly useful.

Here’s a direct link to the calendar, and the link to the iCal. This calendar might change over time, so keep checking it.

Advertisements

Who’s Doing What (Fall 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 at least 24 hours 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:  Current Status, Next Steps, Roadblocks, Questions.  Point form is fine.  Again, these should be collected and posted, and then read by the team 24 hours before the IRC meeting.  This way, we can answer questions in advance, and 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 23rd – minutes: Sampson
September 30th (Sprint weekend) – status reports: Sampson
October 2nd – UCOSP blog post: Jesus

October 7th – status reports: Michelle, minutes: Mike
October 9th – UCOSP blog post: Tina
October 14th – status reports: Wesley, minutes: Karl

October 16th – UCOSP blog post: John
October 21st – status reports: Karl, minutes: Aamir
October 23rd – UCOSP blog post: Sampson
October 28th – status reports: Aamir,  minutes: Allyshia

October 30th – UCOSP blog post: Michelle
November 4th – status reports: Allyshia, minutes: John
November 6th – UCOSP blog post: Wesley
November 11th – status reports: John, minutes: Tina

November 13th – UCOSP blog post: Karl
November 18th – status reports: Tina, minutes: Jesus
November 20th – UCOSP blog post: Aamir
November 25th – status reports: Jesus, minutes: Wesley

November 27th – UCOSP blog post: Allyshia
December 2nd – status reports: Mike, minutes: Michelle

Post-mortem (date TBA)

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

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.