CasablancaNotes
From Google Summer of Code Mentor Wiki
Contents |
[edit] Casablaca
[edit] Background
[edit] The Concept
Casablanca is the name of a conference in building 43 at Google in Mountain View. For the third consective year at the Google Summer of Code Mentor Summit it has been the place for a creative brainstorming session, facilitated primarily by Marty Connor of the Etherboot Project, with essential and much-appreciated help from many mentors who attended the summit, and from the Google Open Source Programs Office.
[edit] Attendees
If you visited Casablanca this year (2008) please add your name here (alphabetical order by first name, please):
- Austin Ziegler, Ruby Central
- Greg Lund-Chaix, OSU OSL
- H. Peter Anvin, Syslinux Project
- Jeff Sheltren, OSU OSL
- John 'Warthog9' Hawley, Git Development Community
- Jonathan "Duke" Leto, The Perl Foundation
- Lance Albertson, OSU OSL
- Marty Connor, Etherboot Project
- Michael Brown, Etherboot Project
[edit] Basic Room Setup
The room is a well-equipped conference room, with a whiteboard, two projectors, and a large, oval conference table with wired internet and power adapters for Macintosh and IBM ThinkPad laptops. It also has comfortable rolling chairs, and room for 15 to 25 people.
[edit] 2009
[edit] Random Links
LIPDUB - I Gotta Feeling (Comm-UQAM 2009) - Single take of a lip sync to "I Gotta Feeling" PLAY-DOH COLOGNE SPRAY
[edit] Bad Movie Night
Announcement of a classic Warthog9 provided "Bad Movie Night" will be held after dinner. Location is 15-20min drive from Wild Palms or Google. Carpools are good.
[edit] Twitter things we liked
Jasebo pointing out that Casablanca now with 10% more win
[edit] boot.kernel.org
Some demos of boot.kernel.org were done (along with fixing a couple of bugs) Things shown:
- Freedos Live
- Doom
- OpenGem
- Ubuntu Live CD
- Open Office
- Debian Live CD
- Open Office
- PXE Knife
Things that were complained about:
- Where's Gentoo! Get on that man!
Things that were awesome:
- Google apparently has *REALLY* phat pipes
- Booting live images over the internet in less than 3 minutes!
[edit] pymt demos
The pymt guys showed off controlling interfaces using legos, camera and little playdoh green dots. All coded while sitting here!
[edit] 2008
[edit] Additional Facilitating Equipment and Supplies
In order to create a relaxed environment that encouraged people to converse freely, certain facilitating supplies and other equipment were provided. These included:
- Lego blocks
- TinkerToys
- Wood Blocks
- PlayDoh
- An iPod with an eclectic mix of music, including:
- Arabic
- Indian Classical
- Senegalese Rye Music
- American Jazz
- Speakers to amplify the iPod and laptops
- HP OfficeJet H470 portable printer
- Post-it flipchart paper to cover the walls
- Lots of flipchart markers
This equipment allowed us a lot of flexibility to be creative, and to create the kind of relaxing atmosphere where we could explore ideas together.
[edit] Flow of Control
[edit] Intention
When writing and speaking I prefer active voice to passive voice, so in the following paragraphs, please understand that it is my (Marty Connor's) view and perspective, and I fully appreciate and respect the views of everyone who participated.
It was my intention and desire that there only be as much structure as required to keep conversation flowing. This worked quite well, perhaps because as mentors and FOSS project members, we are inclined to share with each other and to work collaboratively.
[edit] Sort of like IRC
In some ways the room is like an IRC channel, with topics, people joining and leaving, and with links to interesting content being displayed on the projectors. The conversation can ebb and flow, and everyone can speak.
[edit] Main Topic
On reflection, much of our time was spent reflecting on the question:
- How can we improve the GSoC experience for our organization, mentors, and students?
This general topic led to a lot of sharing and insightful conversation, and seemed to be helpful for many people, because they were free to ask questions and share anecdotes from their individual GSoC experiences.
[edit] Collected GSoC Wisdom
What follows is a somewhat categorized collection of ideas from our conversations in Casablanca. If you participated, please feel free to edit or add to what is here.
[edit] Setting expectations
Much of success during GSoC has to do with setting appropriate expectations. These expectations must be communicated between student and mentor so that before a student is accepted, and well before start of coding student and mentor are aware of what to expect from each other.
By making expectations explicit student and mentor can begin to establish a trust-based relationship, which in turn can make evaluations and code reviews much less stressful on both parties.
Organization GSoC admins may find it useful to converse with mentors well before applications begin arriving to create expectations and structure that will form the basis for how GSoC will be implemented within your particular organization.
[edit] Selection
Selecting qualified students is generally agreed to be a very important factor in determining the success of projects.
Some methods recommended for determining the qualifications of students included:
- IRC interviews
- Code Samples
- Coding Exercises
- Interaction on IRC and mailing lists
These methods are discussed in the following subsections.
[edit] IRC interviews
IRC interviews, though requiring time and effort to arrange have proven to be very effective in the location and selection of qualified students. Project proposals can be unreliable because, like resumes, students can get help in creating them, and thus are of limited utility in determining a student's ability to work effectively in a particular project's environment.
One strategy for interviews is to conduct the IRC interview itself in a private channel, where multiple mentors may converse with a single student. In a second private channel, mentors can converse with each other during the interview to suggest questions or give impressions.
[edit] Code Samples
Having students provide examples of their code is useful in getting a sense of their level of proficiency in coding. Beyond this, it gives mentors something to discuss with prospective students during IRC interviews. Code inspection may lead to discussions of why a particular approach was taken, or may reveal subtle issues with coding that provide a basis for further conversation.
[edit] Coding Exercises
Giving a coding exercise during an IRC interview can be helpful in getting a sense of how proficient a student is in their coding.
One way to conduct a coding exercise is to use a "paste" (sometimes called "pastebin") site to provide a URL referring to the problem description. The student then provides their solution by updating the URL. Questions are encouraged during the exercise, and may be useful in determining how well the student can communicate and ask for help when they need it.
The realtime, full-duplex nature of online coding exercises can provide a useful opportunity to see how students approach problem-solving, and how willing and able they are to accept ideas from others. Do they defend their approach excessively when presented with new ideas? Do they ask for help when they need it?
[edit] Interaction on IRC and mailing lists
Another way to evaluate students is to require them to participate in public project communication venues, such as IRC, mailing lists, and forums. By observing how they communicate and interact with others in the community, one can get a sense of how well they might fit in the social structure of your project.
[edit] Preparation (before Start of Coding)
After students have been selected, preparations for official start of coding can begin in earnest. What follows are some suggestions for creating a managable structure that enables mentors and students to keep status on projects.
[edit] Using a wiki
We have found it very useful to require students to maintain a set of wiki pages to collect and organize information about their project.
A set of GSoC wiki pages is here.
We setup the wiki with the following initial structure for each student:
- An initial page with the following student information:
- Timezone
- Usual working hours
- Time of weekly private IRC meeting with project mentor(s)
- A set of links to the student's
- Project Plan
- Journal
- git repository
- Notes
These pages provide a framework for ongoing status and documentation of each student's project, and provide a way for mentors to non-intrusively monitor their student's progress.
If a student fails to update their journal, they can be reminded during a private weekly IRC conference, or by email or Skype, depending on what form of communication is preferred.
[edit] Require students be ready to code on their first day
Requiring students to be able to build the code base before start of coding means that they can be productive at start of coding. During the "community bonding period" it can be helpful to require students to do some preparation in advance of start of coding.
[edit] Require ability to build codebase
Requiring students to be able to build the codebase before start of coding is a useful way to get them prepared such that they can be productive when official coding begins.
We strongly recommended that sudents be somewhat familiar with the code repository tools (svn, git, cvs), at least enough to do basic operations -- commit, pull, clone, etc.
Creating the expectation and requirement that students be able to build from the codebase and use repository tools will not only make them productive sooner, but will provide an opportunity for mentor and student to discuss any difficulties before coding begins.
Establishing and maintaining this mentor to student communication is vital to providing and environment where students can succeed and mentors feel they are able to appropriately monitor and assist students in achieving their project objectives.
[edit] Require that Project Plan be on Wiki before start of coding
By requiring students to put their project plan on their wiki pages, mentor and student can discuss and refine objectives before coding starts, maximizing the amount of time available for working on the coding task.
[edit] Start of Coding
Once coding begins if preparations have been done well, mentor and student are prepared to begin to work together.
By this point the project should be reasonably well-defined, and expectations between mentor and student should be clear. Conditions may change as the summer progresses, but having a baseline understanding is helpful as a starting point, and developing this understanding can be a good exercise in developing effective communication between mentor and student.
[edit] Evaluation
Make students setup a schedule and make them stick to it. Define consequences. Expectations from the beginning.
Use skype early with your students or a scheduled IRC meeting.
You only have 12 weeks!
Interesting things that happened to your student during GSOC:
Got sued for hacking Boston metro
Have your student let you know if they have prior commitents
Setup a VNC + skype for code reviews
How to give constructive criticism?
How to nicely fail a student?
NOT: You HACK like punk BITCH!
Need inflection in wiki.
Praise in public, punish in private.
We need a "10 minute guide to being a manager for coders"
How to make sure that students understand and know how to use the toolchain required (Makefiles, VCS, necessary libraries, etc...) (make prerequisite)
Estimate developer maturity required for each project.
How do you tell which students are going to "get stuck" ? Are there indicators?
GSOC: Speed Dating on IRC.
Suggestion: have smaller sub-goals allow you to have students not complete 100% but still have a successful project
Setting expectations is critical
Keeping a journal (IRC meetings)
Bad jokes on IRC are incredibly good things, along with open disagreement
Watch bad movies - specific recommendation: Jesus Christ Vampire Hunter
