On 16/03/2012, at 2:07 AM, Boris Bobrov wrote: > В сообщении от Thursday 15 of March 2012 11:07:03 Russell написал: > >> Essentially, we're going to be looking for evidence that you understand the >> scope of the problem you're proposing to solve. Generic statements like >> "I'm going to fix the errors in X" aren't especially convincing by >> themselves. >> >> To put it another way: Our selection process is essentially guided by >> looking at the proposals, and determining what we (as a project) are going >> to get out of the project at the end of the GSoC. A generic plan that says >> "I'm going to spend 12 weeks fixing error messages in Django" doesn't >> really let us know what the end product will be. Will you fix 1 error? 10? >> 100? Will they all be in contrib? django.core? >> >> We also need to be convinced that you appear to understand the complexity >> (or lack of complexity) of the problem you're proposing to fix, and that >> you have a plan that will enable you to deliver on what you're promising. >> A plan that just says "I'm going to fix these 10 problems" without >> providing any details isn't very helpful either. Yes, it would be good to >> have 10 less problems -- but how do we know that the 10 problems can >> actually be fixed in 12 weeks? Or, at the other end of the scale -- how do >> we know that you're not going to be finished in a week? >> >> What we really need is a list of the areas you're going to look at, and >> some sort of analysis of the source of the problems in those areas -- >> e.g., is it just a matter of the error messages being unhelpful, or is >> there something fundamental that needs to be fixed (e.g., internally >> generated exceptions being re-raised in unhelpful ways, or exceptions >> being raised by a side effect, rather than the real problem). >> >> You don't have to go to the level of enumerating every single error message >> you will fix (although that would certainly be nice!), but we will be >> looking for a rigorous analysis. This will require some research and >> elaboration on your part. >> >> A good rule of thumb: Can you produce a convincing timeline for a 12 week >> project? If your project plan is filled with "3 weeks: Fix errors in >> admin", then you haven't provided us with any evidence that you understand >> the scope of the problem. If you can get to 1 week granularity, you're >> starting to be convincing. Granularity at the level of days would be >> excellent. > > Thanks, got it. > What's the deadline for that plan submission? Do I have to send it before the > applications acceptance date, in my application or during the Interim Period > (April 6-20)?
The only deadline is the end-of-submissions deadline, on Friday 6 April. (The April 6-20 period is where we rank and select proposals) The formal submission period starts on 26 March, but we don't enforce that at a project level -- if you want to get started early, please do. > Will it be a one-time submission or some (little) discussion will be held > about it with possibility to fix and change some parts of that plan? We encourage students to send their draft proposals to django-developers so we can give them feedback. This gives us an opportunity to evaluate how you work with the community, and gives you the opportunity to revise and improve your proposals. Obviously, this isn't a completely limitless resource -- you can't send dozens of drafts and expect to get feedback every time -- but it would be unusual for a project to *not* go through at least 2 or 3 revisions. Yours, Russ Magee %-) -- 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.
