| [G] The DOs and DON’Ts of Google Summer of Code: Student Edition Posted: 26 Mar 2011 08:41 AM PDT As Google Summer of Code mentoring organization administrators, we are the people who ensure Google Summer of Code runs smoothly within our organizations. Over the past 6 years, contributors to our four open-source projects ( Gentoo, KDE, XMPP, and X.Org) have read more than 1,000 student applications and mentored hundreds of successful, and unsuccessful, students. Based on our experience with Google Summer of Code, we've built cultural and community practices that strongly favor successful student projects, integration of code, and conversion of students to long-term contributors. We've also seen a lot of things go wrong—repeatedly. We'd like to share these tips and antipatterns with you to raise awareness and help students avoid the same mistakes when taking part in the program. For even more advice, check out the student guide. | DO | DON'T | | Be on your best behavior. Clear, respectful communication is just as important to success today as it was 100 years ago. When you write email or chat on IRC, use complete sentences without any SMS abbreviations (but acronyms are allowed, especially on IRC). If you are unsure about your English skills, there are tools available to help you, such as spell checkers and grammar checkers. On a related note, people want to work with others whose company they enjoy. Be friendly and polite; it's hard to be too much of either. | Make a bad first impression: SMS speech, extremely poor English, rudeness/hostility, etc. These fall into two major categories: failure to communicate and inability to get along with other people. Poor first impressions can seriously damage your chances because both of these problems derail collaboration, which is vital to a successful project. Entirely adequate programmers fail Google Summer of Code because of failures to communicate. | | Read all the documentation, so you submit a useful application. Your application should provide all the detail necessary to convince people that you can accomplish your project, and you're the best person to do it. That means showing you have experience, proving you've done research, and providing a concrete plan. | Submit a useless application. Many varieties of entirely unhelpful applications exist: the one-sentence wonder, the proposal pasted directly from the ideas page, the free-form text that ignores an application template, and the application submitted to the wrong organization. | | Be transparent about other commitments. When organizations know about your commitments in advance, you can work with them to develop a plan that deals with your schedule. For example, you could begin your work at a slower pace during the community-bonding period. If another commitment comes as a surprise to your mentor during the summer, you might not be able to compensate for it. | Disappear. If your mentor thinks you have disappeared during the summer, this tends to quickly result in failure. The most common problem is failing to mention long family vacations or class schedules in the summer. Disappearing includes taking the initial payment and running with it; if you're tempted to do this, you might want to consider the damage to your reputation, or the excited students missing out on a slot so you can waste yours. | | Make Google Summer of Code your top priority. During the 12 weeks of coding time, nothing should take precedence over your project, and you should have no major distractions. If you have another job, decide whether you prefer it or Google Summer of Code and pick one. Make your choice early enough to leave your slot open for another student. | Hold another major commitment. For example, if you have a second job without telling anyone until the start of coding, it's a major problem. Anything outside of the program that takes more than 5–6 hours a week causes problems; this includes classes that extend through the coding period. Two simultaneous full-time jobs is unrealistic. | | Be realistic about your skills. Think through your past experience. If you have trouble fairly assessing your abilities, just write about your coding experience instead and your org can make its own judgment. Additionally, some orgs will gladly provide small sample tasks that you can perform to judge how easy you'll find the summer-long projects. | Over- or under-rate your abilities. As long as you have some programming skill and are able to communicate well (see above), you should be suitable for some projects. This doesn't mean that every student is equal if they meet these requirements. Overselling yourself leads to disappointment; underselling yourself the same. | | Commit and publicize your code frequently. Discussing your code early and often, with your mentor and the broader community, is vital to the success of your project. Make small, easily recoverable mistakes early rather than huge ones when it's too late to do anything about them. | Make last-minute (or later) code drops. Showing your code in public can be scary. Some students wait until the very last minute to show their code to their mentor and other contributors to the project. Do this only if you have a burning desire to fail, because it's too late for any review to fix holes in your code. | | Submit code that's ready to integrate. The best thing about an open source project is seeing your own code shipped in a release and used by thousands or even millions of people. This requires some effort on your part, however. You should closely track how other developers change related code so yours can be easily added to the latest development branch as soon as—or even before—the summer ends. During the last few weeks, make sure your code is polished enough so it's ready to add to the project's main repository; this may require documentation or test suites. Don't let your summer's work go to waste. | Finish the summer with code that's "almost ready" but will take forever to ship. Many students leave their project in a state that is very close to being shippable but isn't quite there yet. Since the mentor tends to be too busy to finish it, these projects ship very slowly, if ever. It's your project—you need to make it see the light of the day. This can require you to keep driving the project, and not trust that the mentor will keep on top of it once the summer is over. | | Complete your project design before writing a line of code. Work with your mentor to define the architecture of your project before you begin coding. You don't need to go as far as prototyping every function, but you should have a vision of how it will all eventually work at a reasonable level of detail, such as important data structures and algorithms. Determine the libraries and tools you'll use, and be able to justify your choices. | Start coding before finalizing design. You can hit major dead-ends when you haven't yet finished working with your mentor to design the project, but you choose to begin coding anyway. For example, if you start coding for a NoSQL backend but your mentor and the rest of the community determine that a standard SQL database should be used, this can necessitate rewriting a lot of code for no reason. Changes on the architectural level can be even more disruptive to any code you've written prematurely. | | Use your resources wisely. Help is just an email away. Don't be afraid to ask questions when you get stuck; we don't expect you to be an expert, and we're happy to answer your questions. On the other hand, remember to do some basic research on your own before asking, such as searching the project documentation, the source code, and Google. | Refuse to ask for help. Throughout the whole program, you will encounter problems that need to be solved—some of them small and some of them large. You can waste days stuck on a problem that can be solved in an hour by talking to other team members. | | Remember that you're part of a community. Very little in Google Summer of Code is 100% independent work. You may propose your project design, but you'll develop it with the help of your mentor and community. You'll write the code, but others will review it, and you'll often build upon their previous work. Unlike school, where a grade could be your first feedback, in Google Summer of Code your grade (pass/fail) is your last feedback. By designing and developing your project in collaboration with your entire open-source community, you'll get people excited about using your work and ready to integrate it. You'll also give yourself the best chance of passing the program by receiving thorough reviews from your community and responding to them. Many students choose to continue contributing after the summer ends because of their interactions with the community. | Consider it a solo project, like it often is in college. It's not; you write the code, but your mentor is there to help with plans, designs etc. Your mentor is not like a lecturer or course leader at a college or university. There's a whole community of people working on the project together, and you should interact with them as a whole. Don't feel like you're working for your mentor, you're working for the community and your mentor is helping guide you, they are not your only point of contact. This has other implications too—other people will be working on the code base while you are, and you will see improvements happening around you as you code. You may need to keep your development branch up to date to take advantage of these. |
|
Making Google Summer of Code the best possible program requires a commitment to excellence from participants at every level. In addition to committing to the program, you must also be thoroughly prepared. In this post we've provided suggestions for students, and in later posts in this series we'll cover mentors and admins. Whatever role you would like to play in Google Summer of Code or a similar program, read everything you can find so you know what you're getting into. Good luck, and have fun in your endeavors. By Donnie Berkholz, Lydia Pintscher, and Kevin Smith, Google Summer of Code Administrators for Gentoo & X.Org, KDE, and XMPP Standards Foundation respectively  |
| [G] The Parrot Foundation Reflects on Google Code-in Posted: 26 Mar 2011 08:41 AM PDT A few of the folks at The Parrot Foundation, one of the mentoring organizations for Google Code-in this year, have offered their assessment of the Google Code-in program. They discuss the wonderful students they worked with over seven busy weeks this winter along with a note to the students that participated in the Google Code-in below.
At first, I was skeptical about whether Parrot should be part of Google Code-in 2010. I was worried that it would be impossible to create small doable tasks for high-school students related to Parrot, and whether it would take up too much developer time to get students up to speed.
Fortunately, I was completely wrong. I was blown away by the caliber of the students that did Parrot-related tasks. They actually rivaled the quality of Google Summer of Code students. Since Google Code-in focused more on mentorship and less on getting a summer stipend, I think it attracted different kinds of students.
Commits to the Parrot Github repo *exploded* during Google Code-in, they almost buried us in pull requests (which isn't a bad thing!) I couldn't believe that high school students were fixing bugs in our cryptography libraries, or improving integration with GDB or refactoring Parrot internals. And to top it off, Google Code-in students translated our README to at least five new languages! Google Code-in literally made the top high school students in the world crawl out of the woodwork.
Not to mention that in the time I have been a Parrot Core Developer, I have never seen such an increase in participation on our IRC channel. Google Code-in added more new faces to our community in a few months than we usually see in a year.
I highly recommend Google Code-in to any organization that is trying to draw in new people. I don't know if anything else can compete with it.
Jonathan "Duke" Leto, Organization Administrator for Parrot Foundation
-----
The most fascinating thing about the 2010-11 Google Code-in for me was the fact that during the peak of the competition we would have four or five Google Code-in students conversing with each other on the Parrot Project's IRC channel, #parrot. These students lived in at least four different countries (U.S., Brazil, France, New Zealand). There were many hours late at night (U.S. time) when all the regular Parrot developers had gone to bed -- but the Google Code-in students kept chatting and hacking away! If only we could harness that energy year-round!
Jim Keenan, Parrot Foundation Mentor
-----
This is a cross-post of part of a blog from the Parrot Foundation directed to the Google Code-in students that participated on their project. For the complete post please click here.
When we Parrot developers first decided that Parrot would be participating in the Google Code-in program, I was quite skeptical. Most of our initial tasks were for translations and many didn't seem to me like they'd help Parrot as a project, especially since Google Code-in was a new (and untested) initiative. If you'd asked me what I though before the start of Google Code-in, I'd say that I had low expectations but would be glad if proven wrong.
I'm glad to say that the amount and quality of the contributions we've received from Google Code-in students has proven me very wrong. We've had a few low-quality results, but the large majority have been of excellent quality. Over the course of Google Code-in, we've added thousands of lines of tests and code, squashed lots of bugs and had several reported, and have increased our test coverage by about 3.5%, all of which represents a great deal of work for a large project like Parrot. As Google Code-in progressed, we've even been able to bump up the difficulty of our "difficult"-rated tasks substantially to challenge our most ambitious students. Parrot is much better off because of the efforts of all of you.
I hope to see all of you continue to make contributions to Parrot after the end of Google Code-in. Your incentives will be different from now on, but they'll also become much more exciting. If you're interested and don't know quite what you want to do, we'll always try to help you find something awesome to keep you busy. Please stick around and keep on hacking!
Thanks,
Christoph Otto, Architect, Parrot VM
-----
Thank you Parrot Foundation and all of our other mentoring organizations and the amazing students for making Google Code-in a huge success! By Stephanie Taylor, Open Source Programs Office  |
| [G] Googler Eric Clayberg joins Eclipse Foundation Board Posted: 26 Mar 2011 08:41 AM PDT Google Software Engineering Manager Eric Clayberg has been elected by the Eclipse community as a Sustaining Member Representative on the Eclipse Foundation Board of Directors for the 2011-12 term. The announcement was made yesterday at the Annual General Meeting during the kick-off of EclipseCon 2011 in Santa Clara, CA. As a member of the Board of Directors, Eric will help oversee the policies and strategic direction of the Eclipse Foundation. Eric works on the Google Plugin for Eclipse ( GPE) team at Google and he was formerly with Instantiations, a company known for its focus on Eclipse Java developer tools, that was acquired by Google in 2010. Eric is also a Project Lead for the new open source WindowBuilder project at Eclipse.org. "I have been involved with Eclipse since 1999 and have always been a strong supporter of Eclipse community interests. I look forward to bringing Google scale thinking and inventiveness to my new role as board member." Google has been a longtime supporter of the the Eclipse Community. In addition to open sourcing Eclipse tools, Eclipse Labs is powered by Google Project Hosting and we have hosted Eclipse Days at the Googleplex in 2010, 2009, and 2008. Several Googlers will speak at EclipseCon sessions this year, including: We hope to see you you at EclipseCon 2011! Bruce Johnson and Chris Ramsdale, Google Developer Tools Team  |
| [G] Now Playing: the YouTube Symphony Orchestra Augmented Reality Experiment Posted: 26 Mar 2011 08:41 AM PDT The YouTube Symphony Orchestra is built on technology and innovation–musicians audition by uploading videos of themselves performing, and then YouTube viewers select who they want to participate in the live-streamed performance. Yesterday the YouTube Symphony Orchestra 2011 performed their Grand Finale Concert* from the Sydney Opera House, which was live-streamed around the world on YouTube. Even though the performance is now over, the music and innovation continues! The 2011 YouTube Symphony Orchestra's Augmented Reality "Experiment" is an interactive way for fans to make some music of their own. By waving an easily made marker in front of a webcam, users can create and record music on a virtual instrument, then share their creations with friends. This virtual instrument was created as a collaboration between YouTube, Tellart, and Hyundai, and in the spirit of innovation, the software for the performance interface (the augmented reality application that actually makes the music) is now open source. You can now download the source and build an augmented reality instrument of your own. More details are available on the YTSO AR Instrument Project website. By Ellen Ko, Open Source Team
*The performance was accompanied by sophisticated projections on the interior and the exterior on the iconic sails. A helicopter was used to laser map the sails in 3D to make it happen!
 |
| [G] Mentoring Organizations for Google Summer of Code Announced Posted: 26 Mar 2011 08:41 AM PDT  We are pleased to announce the list of mentoring organizations that have been accepted for this year's Google Summer of Code program. After reviewing 417 applications, we have have narrowed the list to 175 open source projects, 50 of which are new to Google Summer of Code. You can visit our Google Summer of Code 2011 program website for a complete list of the accepted projects. Students wishing to apply for Google Summer of Code will have the next 10 days to learn more about the accepted projects before student applications open on Monday, March 28, 2011 at 19:00 UTC. Students will want to pay close attention to the Ideas Pages for the organizations they wish to work with over the summer and consider how they would like to contribute to the project. Some of the most successful proposals have been completely new ideas submitted by students, so if you don't see a project that appeals to you, don't be afraid to suggest something. Organizations have listed points of contact on their Ideas Page so students can contact the organization directly to submit a new proposal. All organizations list their preferred method of communication on the organization homepage which is available on the Google Summer of Code program website. Please see our Frequently Asked Questions page for more information. Congratulations to all of our future mentoring organizations! We look forward to working with all of you during this exciting 7th year of Google Summer of Code!
By Stephanie Taylor, Open Source Programs Office  |
No comments:
Post a Comment