Hello everyone, Django has once again been accepted as one of the participating projects for Google Summer of Code, and so we're now looking for student projects! I've taken over the role of GSoC administrator from Jannis this year; feel free to email me directly (or catch me on IRC) if you have any problems or want to discuss something about the program.
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. It's an excellent chance for you to get involved in open source without worrying about having to get a summer job for income; Django have been doing GSoC since 2006 and several core committers are former GSoC students. For more details about Summer Of Code, including the timeline, payment amounts, and how students are expected to participate, check out Google's FAQ: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs If you're interested in working on Django as part of GSoC please read this whole email (much thanks to both Jannis and Jacob for providing previous iterations of much of this text). Important dates --------------- The whole timeline can be found on Google's GSoC site, but there's a couple of important dates you should be aware of right now: The student application period opens March 28th and ends April 8th (19:00 UTC). Remember, the April 8th deadline is a *hard* deadline: no applications filed late will be considered. This means you've got a little more than two weeks to prepare your application, so the time to start is *right now*. Picking a project ----------------- 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/SummerOfCode2011 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; while 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. It also helps if you mark the discussion subject with [GSoC], so we can easily see that you want feedback relatively quickly. 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 are only 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 on the GSoC website (http://www.google-melange.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-developers. - 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 that. - 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 clichéd, but a badly written application is a real turn-off. If you can't write an important document like that and use spelling, 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. Next steps ---------- If you've read all that -- and congratulations, by the way! -- the next things to do are: - Start looking for a project, and draw up some rough plans. - Get an initial proposal together, and post it to django-developers. Good luck, and we look forward to your proposals! Andrew -- 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.
