Welcome, Drupal Summer of Code 2009 Students!

Events happening in the community are now at Drupal community events on www.drupal.org.
alex ua's picture

Welcome, accepted Summer of Code students! This post contains important information about prerequisites for starting your project. Please read it carefully.

Google has awarded Drupal 18 slots for the 2009 Google Summer of Code. This year there were many strong applications, and narrowing the field to the top 18 was not an easy task. Thanks to all the mentors who helped out with the evaluating, and congratulations to all of the students. We look forward to working with you this summer! :)

Although coding doesn't formally kick off until May 23, according to Google's program timeline, there are a few things that need to get sorted out first. If you have questions about how to do any of these things, don't be shy! :) Post to the http://groups.drupal.org/soc-2009 or ask in #drupal on irc.freenode.net, and we'll get you hooked up.

  1. Create a central wiki page for your project at the SoC 2009 group. This wiki page should basically be a single location that anyone can read over the course of SoC in order to get a good sense of what your project is about, and where it is currently in terms of completion. There's a template you can copy and paste available at http://groups.drupal.org/node/21558. Add a link to your project in here

    This page should be updated when you and your mentors reach a major design decision about your project, or if your schedule and/or deliverables need to be adjusted. Use the SoC 2008 group as a tool to help you achieve your goals. Ask questions. Find people to help you test. Discuss design decisions. Post mockups. Be creative.

  2. Obtain a CVS account. The code that you produce during Summer of Code will ultimately reside at cvs.drupal.org, and you need to apply for a CVS account if you don't already have one. In your application, please mention that you are a Google Summer of Code student, so that your account will get approved quickly.

    If you're new to CVS (or revision control systems in general), you might find our CVS handbook helpful, particularly the CVS introduction. Additionally, the CVS quickstart guide is handy to have around as a reference.

  3. Create a "project" on drupal.org for your project (even if your delivery is an improvement to an existing module). Once you have CVS access, describe your project briefly in a README.txt and add a sub-folder for it to the contribution repository's modules/ directory, then create a "project" for it on drupal.org, following the instructions at Step-by-step: Create a CVS project. This will give you several tools at your disposal, including:
    • a central project page, which you can use to document your project and its current state.
    • an issue tracker, which you can use to break your project apart into sub-tasks and track their completion status. Using the issue tracker allows your mentors (or any other community members) to provide input on your development process.
    • the ability to create project releases, which testers can download and try out on their own Drupal installations.

    There is helpful information about working with these tools available in the Maintaining d.o projects with CVS guide. Note that issue tracker and CVS commit activity will be primary methods of evaluating projects, and we require you to create an issue every week to report . These show us that you're making progress each week, and should be titled "Milestone X" and tagged with "SoC 2009 Weekly Update".

  4. Meet your mentors and discuss your project. Please investigate which means of communication your mentors prefer. Communication is a crucial element of success, and you are encouraged to use email, Skype, IRC (http://drupal.org/node/108355), the SoC 2009 group (http://groups.drupal.org/soc-2009), the devel list (http://drupal.org/mailing-lists), and any other resources that are available to make sure that the lines of communication between you and your mentor are well established and open for the duration of the summer.

    Ensure sure that any broad or project management-related changes are documented in your wiki page, and any code-related decisions/feedback is reflected in your project's issue queue, for the benefit of those who didn't have a chance to take part in your personal communication.

  5. Refine the scope of your project. Discuss with your mentors whether they feel the scope of the project described in your application is realistic and clear. If there are ambiguities, try to iron them out. We're looking for clearly stated deliverables that you feel confident you can produce by the end of the summer. Update your project's wiki page with the result.
  6. Plan on testing. It is a requirement for this year's Summer of Code projects to include test scripts. For most people the simpletest framework will be the best solution. See documentation at http://drupal.org/simpletest.

If you have any questions to one of the points above, your mentor will be able to help you (or ask here).

We're looking forward to working with you.

Happy Coding,

Drupal's Google Summer of Code team

Comments

Note for rejected students

jpetso's picture

I also want to note that if you were not selected, this does not mean that your application was not worthy of being accepted, it just means that we get enough slots from Google to hand out. We had at least 10 more projects that would have absolutely deserved to be supported, and for most of them we had already found mentors.

So if you're not in the "final list" but still motivated to work on your project without Google's financial support, we should still be able to provide you with mentoring support, introduction in the community and workflows, and a T-Shirt from Google (although one from Leslie's Open Source Programs Office, not the original Summer of Code one). Just let us know if you're still interested, and we can work it all out.

internship certificate

Shahina's picture

Sir i want to know whether you will provide me with internship certificate if i work on project?
Secondly i m living in Pakistan and i m really interested in doing internship but can't come their.Please let me know whether i can apply for it?

nope

jpetso's picture

Sorry, no internship certificate - only Google can hand those out, and only accepted students will receive one. Several companies have stated their interest in interns on this page, but I'm not sure whether those internships apply to rejected GSoC students only or to interested developers in general.

I'm confused about item 3.

aaron's picture

I'm confused about item 3. For an existing project (such as the Media project), you say he's supposed to start a new project regardless. Will we just plan to merge work from that into the main project, and have the soc project be temporary?

Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)

Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic

same question here

marvil07's picture

My gsoc project is related with versioncontrol module and its backends.

I do not see the need of have one for my case. I would propose use a some tags on issues. In my case: gsoc, gsoc2009, Version Control API and family changes

Well, I'm not really sure about the last one identifing the project, but it a first propose, what do you think?

i'm positive

jpetso's picture

I would consider tags an appropriate way to categorize issues. My reservations against new projects for existing modules is less that they are unnecessary but more that they don't reflect the way that drupal.org normally works, and when SoC ends they will be left with no purpose. I think we should discuss the "new project" requirement in more detail, especially since a good share of the SoC projects do indeed work on existing modules rather than create new ones.

OK, sounds like a consensus

alex ua's picture

After talking it over with webchick I think that the tagging solution is fine. Before I update this post, and add a discussion announcing it so students see it, does anyone have suggestions on exactly how we should use the tags? The only caveat here is that the module maintainer is going to have to agree to this, but I doubt that will be an issue.

We also need to make sure the students are aware that they must submit their code to google in order to get paid, so they're going to need to track their contributions.

--
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Tagging + CVS commit messages?

mbutcher's picture

If I interpret this correctly, the idea is to track a student's progress using our tools, correct?

So if we can track the student's work with CVS commit messages and also with issue queue tags, we should have all of the data we need for data collection, correct?

Regarding CVS commit messages, we can obviously use the student's CVS login as one way of tracking. We could, if necessary, require that the commit message contain 'gsoc', though I suspect that might be more of an inconvenience than it is worth.

Matt Butcher
Blog: http://technosophos.com
QueryPath: http://querypath.org

If I interpret this

alex ua's picture

If I interpret this correctly, the idea is to track a student's progress using our tools, correct?

That's correct.

So if we can track the student's work with CVS commit messages and also with issue queue tags, we should have all of the data we need for data collection, correct?
Seems like we should. The main question is, how should we do the tagging? A single tag for GSoC 2009? A tag for each project? As Greg suggeted we also can use the title for items such as milestones.

One goal here would be to create the data in a way that it could be easily and logically pulled from d.o. to another site (or even just to a spreadsheet) for analysis.

Regarding CVS commit messages, we can obviously use the student's CVS login as one way of tracking. We could, if necessary, require that the commit message contain 'gsoc', though I suspect that might be more of an inconvenience than it is worth.

I guess it might be unnecessary to add a tag to CVS messages, since as you point out we could just track their commits through their Code Tracker. Anyone else have an opinion on this?

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

propose for tags

marvil07's picture

Today, talking on irc with jpetso, sdboyer and chrono325 we agree on using two tags per issue related with gsoc, one to group all this year gsoc work and the other for student.

For example, I've just created an issue with gsoc2009 and gsoc2009-marvil07 tags.

I think is a good idea, so maybe others wants to use this approach too.

SoC 2009

Group categories

Admin Tags

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: