Hi folks -- It's that time of year again: Google's announced the Summer of Code 2009, and Django is again one of the participating projects. Jannis Leidel will be running things this year, and I'll be backing him up.
For those who aren't aware: Summer of Code is Google's program to pay students to work on open source projects over the summer. I can't think of a better summer job if you're a student and want to get involved in open source. For more details about the program in general, check out Google's FAQ: http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs. If you're interested in working on Django as part of GSoC please read this whole email. It's quite long, and I apologize for that, but we've learned over past years a lot about what makes a GSoC project succeed or fail. Last year was our most successful year to date, and I'm determined to make this year even better. Important dates --------------- The whole timeline can be found in the FAQ, but there's a couple of important dates you should be aware of right now: The student application period opens March 23 and ends April 3. There's no prizes for getting your applications in first, but that April 3 deadline is a *hard* deadline: no applications filed late will be considered. This means you've got two weeks to prepare your application, so the time to start is *right now*. Picking a project ----------------- [Thanks to Malcolm for some of the content below; I shameless ripped some stuff off from an email he wrote yesterday.] The first thing you need to do is choose something to work on. Hopefully if you're reading this you've already got an idea; if not, there's some ideas at http://code.djangoproject.com/wiki/SummerOfCode2009. However, if you just pick something there and throw together a quick application, you're going to get rejected immediately. There's a lot more to choosing a project that just throwing something together. We've found over the past years that the pickier we are about application quality, the better the final projects are. Because we want success this year, we're going to be exceedingly picky about only accepting good applications, so it's vital that you put your best foot forward. Here's how: Think of the process as applying for a job. You're trying to convince us that you: (a) understand the problem you're attempting, and (b) have some chance of achieving something realistic in the 12 week period you've got to work. This can be hard, particularly for people haven't been involved in Django development before -- some projects require a history of involvement before applying; we let anybody apply. So it's really *now* that you want to start getting involved. You have to put in a little bit of work to work out how your problem might be approached, or what the current problems are. Don't just pick something from the ideas page -- you could also look through Trac and view the tickets grouped by component and see if there's a bunch of things in a similar area that suggests something needing more holistic attention. Most importantly, though, when you have some kind of idea, start a discussion on django-developers. This will let us help you understand what you're up against, and it'll help us see that you've got the knowledge to tackle the problem. Last year, to pick one example, Nicolas Lara, who helped implement aggregates support, was involved in quite a long discussion about it leading up to the project start. This meant that by the time he filed his application, he knew the problem space very well, and had a well-reasoned proposed solution. Timing is a little tricky this year, because a bunch of the core developers are heavily focused on getting Django 1.1 out. So mention in the post that it's a SoC discussion, and we'll make sure to give it some attention. (If you don't mention that, somebody will say "wait until 1.2"). The applications that have been most successful in the past -- in terms of producing working code at the end of the period, rather than just being accepted -- are those where the applicants have engaged a bit ahead of time to see if their ideas stand up to review and/or tweak those ideas a bit. Once you've had one of these discussions, *then* you're in a position to write an application that can lay out your cunning plan and point to a discussion showing it kind of holds up under scrutiny. We have much more confidence voting for a student who's done the preparation than somebody with no history whatsoever. Many SoC students starting to get into Django, which means you have to do some work here and get a feeling for what you're up against. In short, the application isn't a "convince us to let you work on this for the summer" as much as "convince us you understand the problem you're proposing to work on and that your solution has a chance of working and being accepted by the core body of developers". Our goal this year is for *every single project* to result in code that gets committed back to Django. We'll accomplish this goal by *rejecting* applications that don't show us good odds of success. What a good proposal looks like ------------------------------- Once you've got some discussion done, and have a handle on the task, you'll need to submit your proposal into Google's SoC web app (http://socghop.appspot.com/). We'll be looking for a few things in your proposal: - A concise but complete description of the problem. - A concrete, as detailed as you can, proposal of how you plan to modify Django to fix said problem. This is where you'll include links to your previous discussions on django-dev. - A timeline, ideally broken into week or two-week chunks, showing the steps you plan to take as you work on the problem. This is obviously subject to change, but it'll show us that you have a handle on the scope of the problem. You should also indicate roughly how much time (hours/week) you can devote to the problem. Some folks work full-time (40+ hours/week) on SoC. Less is OK, but if you've only got weekends free we'd like to know about. - Some information about yourself, including why you think you're qualified to work on this problem. We don't need or want a resume, but include any relevant information about you and your background that'll help us get a feel for who you are. What a bad proposal looks like ------------------------------ Just to round things out, a couple of things that happen in applications that have absolutely no chance: - Somebody we've never heard of proposing something *really* ambitious. It's not too hard to guess roughly at the required amount of work, for those of use who maintain Django or work regularly on the internals, so if somebody proposes something that's too hard, we can tell. And if we don't know them at all, it's hard to trust they'll get things done. - However, the, the problem shouldn't be too small. It's called Summer of Code, not Weekend of Code. - A proposed change without any evidence on django-dev or django-users (or elsewhere) that the change is needed. We make changes because there are use-cases for them, not because we can. So any proposal should be driven by trying to fix some existing problem, not creating a "wouldn't it be nice if...?" situation. - This will sound cliched, but a badly written application is a real turn-off. If you can't write an important thing like that and use spelling and grammar and sentences with at least some punctuation, we'll worry about your ability to communicate effectively with your mentor and the community. There's a lot of people in our community who don't speak English as a first language. *That's* not a problem; we're not going to be grading you! However, we need to see that you can communicate clearly, and so basic proofreading is a must. We're not asking for Shakespeare -- though a proposal in iambic pentameter would thrill me and annoy Malcolm; double win -- but it needs to rise above IRC speak. Next steps ---------- If you've read all that -- and congratulations, by the way! -- the next things to do are: - Start looking for a project. - Subscribe to the django-gsoc mailing list (http://groups.google.com/group/django-gsoc); we'll use this list to conduct most of the business of GSoC. Let's do it! Jacob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
