On 15/03/2012, at 1:23 PM, Boris Bobrov wrote:
> Hi!
> I'd like to participate in GSoC-2012 and the interesting task for me is [0].
>
> What kind of plan would you expect from me? Should it be detailed ("I'll fix
> error handling in part X by doing A") or it can be more general ("I'll fix
> error handling in part X after reviewing A, B, C") or even move general
> ("I'll
> fix error handling of cases listed on [1] and some others I've met in my
> practice")?
>
> The problem is that I don't know all the places with such poor error
> handling;
> and the list on [1] is incomplete, I've met some useless error messages
> myself, in templates mostly. Though a lot can be found by googling
> "site:stackoverflow.com django weird strange error".
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.
> Another question - can I use code written by other people as patches in
> django
> bugtracker for my GSoC project?
As far as I understand the rules -- yes, as long as you're also making a
significant contribution yourself. Your project can't just be "I'm going to
merge these 10 patches"; you need to actually produce some code of your own.
> [0]:https://code.djangoproject.com/wiki/SummerOfCode2012#Improvederrorreportin
> [1]:https://code.djangoproject.com/wiki/BetterErrorMessages
> --
> WBR,
> Boris.
--
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.
