Re: [GSoC 2013] Improving code quality

[Damian Skrodzki]

Thanks for all the discussion!

You convinced me that focusing on particular project and being able to 
detail it - not looking for the best one in meaning of usefulness is the 
key here. Also I did not take into account variable number of slots. 
However I'm going to review *all* projects again and maybe I'll choose 
another in order to find the one that would be easier to precise and 
schedule.

I'm rather interested in joining Django community than solving particular 
problem.

Big thanks again,
Damian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] Improving code quality

[Jacob Kaplan-Moss]

On Thu, Apr 18, 2013 at 6:42 PM, Russell Keith-Magee
 wrote:
> So - the secret to getting into the GSoC isn't the project title you pick -
> it's the quality of your proposal.

This. A thousand times this.

I think there's a perception among people applying to GSOC that we're
judging the project. This is not true. In fact, when we judge
proposals the actual project is almost an afterthought! Our main goal
is to pick students that *will actually deliver*: I'll always vote for
a proposal I find unexciting but realistic over one that proposes
something awesome that seems like it won't get done.

You main goal should be to prove to us that you can deliver. If you
can't prove your ability to Get Things Done, then what you're
proposing to do kinda doesn't matter.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] Improving code quality

[Russell Keith-Magee]

On Fri, Apr 19, 2013 at 3:52 AM, Alex Ogier  wrote:

> I wouldn't claim to speak for Django GSoC mentors and what they will
> accept, but I can say that the "Improve Django's code/error handling"
> projects have been perennial on Django's Recommended Project list for a
> while now, I think without any successful proposals (though "Improve
> Django's security" is philosophically somewhat similar and that *did* get
> accepted and worked on last year).
>
> I think the problem is that it's super hard to write a proposal in this
> area that gets Django people nodding and saying "Yeah, this sounds really
> helpful, it's definitely something we should look at." Of course a lot of
> people are interesting in Django's code getting better over time, but
> people are resistant to lots of little refactorings with no external
> benefit, because it's usually not clear up front that the internal benefit
> will be enormous and any code changes introduce the possibility of new bugs
> or flaws.
>

Not entirely true.

A little bit of "how the sausage is made": I've been mentoring the GSoC for
something like 6 years now. In all that time, I don't think Django has
needed to turn down a single proposal that we *wanted* to accept. The
number of proposals we accept pretty much exactly matches the number of
good proposals - in fact, it's probably a little higher, since we've given
some people the benefit of the doubt… and there's a reasonably high
correlation between the poor proposals we've accepted, and the proposals
that have completely failed.

The reason internal refactoring projects are harder to get up isn't because
they're less 'sexy'; it's because they're harder proposals to write. It's
easy to throw out a draft API and say "I'm gonna build *that*". It's a lot
harder to explain exactly how to plan to rework a complex piece of existing
internals.

So - the secret to getting into the GSoC isn't the project title you pick -
it's the quality of your proposal.

You need to be able to describe exactly what you're planning to do. We need
to know *exactly* what we're going to get at the end of the GSoC.

You need to be able to define a timeline for your project. That timeline
needs to be very specific - saying "6 weeks - fix all the things" isn't
acceptable. Granularity of 1 week is pretty much the upper limit. We need
to be able to accurately assess your project.

You need to structure your proposal in a way that it's clear how we're
going to action it. What are we going to get at the end? One big patch?
Lots of patches, but all incrementally dependent on each other? Lots of
independent patches?

You need to have failsafes. What happens if something technical prevents
project completion -- is there any path by which we can rescue something
useful from your efforts?

You need to be able to demonstrate that you actually understand the
problem. If you're talking about a new API, you need to be able to either
define that API, or provide enough of a draft that indicates you've got a
workable plan. If you're talking about improving something, you need to
give specific details on what you're planning to improve.

In short - convince us that you, as someone who is relatively or completely
unknown to the Django core team, have a concrete plan to do something
useful, that you have the skills to execute that plan, and that we have a
clear ability to assess your progress.

I hope that gives a little more guidance.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] Improving code quality

[Alex Ogier]

I wouldn't claim to speak for Django GSoC mentors and what they will
accept, but I can say that the "Improve Django's code/error handling"
projects have been perennial on Django's Recommended Project list for a
while now, I think without any successful proposals (though "Improve
Django's security" is philosophically somewhat similar and that *did* get
accepted and worked on last year).

I think the problem is that it's super hard to write a proposal in this
area that gets Django people nodding and saying "Yeah, this sounds really
helpful, it's definitely something we should look at." Of course a lot of
people are interesting in Django's code getting better over time, but
people are resistant to lots of little refactorings with no external
benefit, because it's usually not clear up front that the internal benefit
will be enormous and any code changes introduce the possibility of new bugs
or flaws.

Best,
Alex Ogier


On Wed, Apr 17, 2013 at 4:42 PM, Damian Skrodzki wrote:

> And how would you rate the chances that these projects will be selected
> for GSoC? Or which of all proposed projects have the most priority to you?
> I'd be very happy to join Django community and have chance to improving
> code quality (not only adding new features) would also be great.
>
>
> On Tuesday, April 16, 2013 1:04:12 AM UTC+2, Russell Keith-Magee wrote:
>
>>
>> Yes - I was referring to error reporting. Although the same would be true
>> for 'best practices'.
>>
>> Yours,
>> Russ Magee %-)
>>
>> On Mon, Apr 15, 2013 at 3:22 PM, Damian Skrodzki wrote:
>>
>>> Thanks for the answer.
>>>
>>> Just to be sure. As "Take the first project" you mean "2. Improved
>>> error reporting", correct? I wrote the whole post in reversed order which
>>> could confuse you.
>>>
>>> On Monday, April 15, 2013 2:18:56 AM UTC+2, Russell Keith-Magee wrote:
>>>


 On Mon, Apr 15, 2013 at 7:51 AM, Damian Skrodzki wrote:

> Hi,
>
> After looking through proposed ideas for the current GSoC i found 2
> issues related close to the code quality which I'm interested in. These 
> are:
>
>
>1. Best practices Updates
>2. Improved error reporting
>
> Both tasks are a different but they are very closely related just to
> code quality which if very important especially in projects in size of
> Django ;). I will try to suggest that maybe merging them into one little
> bigger task would be better idea. I'll explainin characteristics of these.
>
> Take the second one as a first. This project will require trying to
> reproduce some bugs and fix some error handling in order to allow other
> developers to fix their bugs more easily. I think that trying to analyse
> code, predict all scenarios and write all expected messages seems like
> impossible task. It's better to fix tasks already reported by users. So
> here comes the list https://code.**djangoprojec**t.com/wiki/**
> BetterErrorMessages
> **. **Unfortunately (or rather fortunately) I found many of the
> issues from "error handling" are outdated. On the other side it would be
> good to review that list and possibly fix that wrong messages but ... do
> you think that fixing few error handlers is enough for 2-month project?
>
> The first one will require to know best practices and then
> rewrite/update some code to follow them. I think that this could
> be continuous task, and the finish of this task if very blurred. Common
> sense tells me that we should start with refactoring from "the worst" code
> then current worst and keep doing until all project will be up to current
> best practices. When the big project is being developed constantly there
> always be some code that need refactoring.
>
> My idea would be to fix issues from bad "error messages list" which is
> definitely achievable and then start to refactoring few functionalities of
> Django that very needs it. To make the second part more achievable and
> precise, I should choose few particular functionalities the I'd like to
> take care of. This approach will allow to fix particular bugs reported by
> users. Moreover fixing simpler bugs is usually easier to start with
> project. Then having bigger knowledge i could refactor some code.
>
>
> Do you think that it's reachable to do that in described way?
> Or maybe better stick to the idea of taking just 1 of this projects
> and spend some more time on it?
>

 I think that if you do a detailed analysis, you'll find that *both*
 projects could easily fill a full GSoC semester.

 Take the first project -- the wiki is there as a documented list of
 known problems, not a comprehensive list of all problems. A comprehensive
 audit of everywhere that Django 

Re: [GSoC 2013] Improving code quality

[Damian Skrodzki]

And how would you rate the chances that these projects will be selected for 
GSoC? Or which of all proposed projects have the most priority to you? I'd 
be very happy to join Django community and have chance to improving code 
quality (not only adding new features) would also be great.

On Tuesday, April 16, 2013 1:04:12 AM UTC+2, Russell Keith-Magee wrote:
>
>
> Yes - I was referring to error reporting. Although the same would be true 
> for 'best practices'. 
>
> Yours,
> Russ Magee %-)
>
> On Mon, Apr 15, 2013 at 3:22 PM, Damian Skrodzki 
>  > wrote:
>
>> Thanks for the answer.
>>
>> Just to be sure. As "Take the first project" you mean "2. Improved error 
>> reporting", correct? I wrote the whole post in reversed order which could 
>> confuse you.
>>
>> On Monday, April 15, 2013 2:18:56 AM UTC+2, Russell Keith-Magee wrote:
>>
>>>
>>>
>>> On Mon, Apr 15, 2013 at 7:51 AM, Damian Skrodzki wrote:
>>>
 Hi,

 After looking through proposed ideas for the current GSoC i found 2 
 issues related close to the code quality which I'm interested in. These 
 are:


1. Best practices Updates
2. Improved error reporting

 Both tasks are a different but they are very closely related just to 
 code quality which if very important especially in projects in size of 
 Django ;). I will try to suggest that maybe merging them into one little 
 bigger task would be better idea. I'll explainin characteristics of these.

 Take the second one as a first. This project will require trying to 
 reproduce some bugs and fix some error handling in order to allow other 
 developers to fix their bugs more easily. I think that trying to analyse 
 code, predict all scenarios and write all expected messages seems like 
 impossible task. It's better to fix tasks already reported by users. So 
 here comes the list https://code.**djangoproject.com/wiki/**
 BetterErrorMessages
 . **Unfortunately (or rather fortunately) I found many of the issues 
 from "error handling" are outdated. On the other side it would be good to 
 review that list and possibly fix that wrong messages but ... do you think 
 that fixing few error handlers is enough for 2-month project?

 The first one will require to know best practices and then 
 rewrite/update some code to follow them. I think that this could 
 be continuous task, and the finish of this task if very blurred. Common 
 sense tells me that we should start with refactoring from "the worst" code 
 then current worst and keep doing until all project will be up to current 
 best practices. When the big project is being developed constantly there 
 always be some code that need refactoring.

 My idea would be to fix issues from bad "error messages list" which is 
 definitely achievable and then start to refactoring few functionalities of 
 Django that very needs it. To make the second part more achievable and 
 precise, I should choose few particular functionalities the I'd like to 
 take care of. This approach will allow to fix particular bugs reported by 
 users. Moreover fixing simpler bugs is usually easier to start with 
 project. Then having bigger knowledge i could refactor some code.


 Do you think that it's reachable to do that in described way?
 Or maybe better stick to the idea of taking just 1 of this projects and 
 spend some more time on it?

>>>
>>> I think that if you do a detailed analysis, you'll find that *both* 
>>> projects could easily fill a full GSoC semester. 
>>>
>>> Take the first project -- the wiki is there as a documented list of 
>>> known problems, not a comprehensive list of all problems. A comprehensive 
>>> audit of everywhere that Django internally catches and re-raises 
>>> exceptions, and how the stack track from those exceptions are exposed, 
>>> would *easily* consume 12 weeks. 
>>>
>>> However, we're not going to accept a project proposal that has a 
>>> schedule of "audit code for 12 weeks". We're going to need you to do some 
>>> initial exploration and give us a more detailed list of the sorts of 
>>> problems you're going to look at.
>>>
>>> Yours,
>>> Russ Magee %-) 
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To 

Re: [GSoC 2013] Improving code quality

[Russell Keith-Magee]

Yes - I was referring to error reporting. Although the same would be true
for 'best practices'.

Yours,
Russ Magee %-)

On Mon, Apr 15, 2013 at 3:22 PM, Damian Skrodzki wrote:

> Thanks for the answer.
>
> Just to be sure. As "Take the first project" you mean "2. Improved error
> reporting", correct? I wrote the whole post in reversed order which could
> confuse you.
>
> On Monday, April 15, 2013 2:18:56 AM UTC+2, Russell Keith-Magee wrote:
>
>>
>>
>> On Mon, Apr 15, 2013 at 7:51 AM, Damian Skrodzki wrote:
>>
>>> Hi,
>>>
>>> After looking through proposed ideas for the current GSoC i found 2
>>> issues related close to the code quality which I'm interested in. These are:
>>>
>>>
>>>1. Best practices Updates
>>>2. Improved error reporting
>>>
>>> Both tasks are a different but they are very closely related just to
>>> code quality which if very important especially in projects in size of
>>> Django ;). I will try to suggest that maybe merging them into one little
>>> bigger task would be better idea. I'll explainin characteristics of these.
>>>
>>> Take the second one as a first. This project will require trying to
>>> reproduce some bugs and fix some error handling in order to allow other
>>> developers to fix their bugs more easily. I think that trying to analyse
>>> code, predict all scenarios and write all expected messages seems like
>>> impossible task. It's better to fix tasks already reported by users. So
>>> here comes the list https://code.**djangoproject.com/wiki/**
>>> BetterErrorMessages
>>> . **Unfortunately (or rather fortunately) I found many of the issues
>>> from "error handling" are outdated. On the other side it would be good to
>>> review that list and possibly fix that wrong messages but ... do you think
>>> that fixing few error handlers is enough for 2-month project?
>>>
>>> The first one will require to know best practices and then
>>> rewrite/update some code to follow them. I think that this could
>>> be continuous task, and the finish of this task if very blurred. Common
>>> sense tells me that we should start with refactoring from "the worst" code
>>> then current worst and keep doing until all project will be up to current
>>> best practices. When the big project is being developed constantly there
>>> always be some code that need refactoring.
>>>
>>> My idea would be to fix issues from bad "error messages list" which is
>>> definitely achievable and then start to refactoring few functionalities of
>>> Django that very needs it. To make the second part more achievable and
>>> precise, I should choose few particular functionalities the I'd like to
>>> take care of. This approach will allow to fix particular bugs reported by
>>> users. Moreover fixing simpler bugs is usually easier to start with
>>> project. Then having bigger knowledge i could refactor some code.
>>>
>>>
>>> Do you think that it's reachable to do that in described way?
>>> Or maybe better stick to the idea of taking just 1 of this projects and
>>> spend some more time on it?
>>>
>>
>> I think that if you do a detailed analysis, you'll find that *both*
>> projects could easily fill a full GSoC semester.
>>
>> Take the first project -- the wiki is there as a documented list of known
>> problems, not a comprehensive list of all problems. A comprehensive audit
>> of everywhere that Django internally catches and re-raises exceptions, and
>> how the stack track from those exceptions are exposed, would *easily*
>> consume 12 weeks.
>>
>> However, we're not going to accept a project proposal that has a schedule
>> of "audit code for 12 weeks". We're going to need you to do some initial
>> exploration and give us a more detailed list of the sorts of problems
>> you're going to look at.
>>
>> Yours,
>> Russ Magee %-)
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] Improving code quality

[Damian Skrodzki]

Thanks for the answer.

Just to be sure. As "Take the first project" you mean "2. Improved error 
reporting", correct? I wrote the whole post in reversed order which could 
confuse you.

On Monday, April 15, 2013 2:18:56 AM UTC+2, Russell Keith-Magee wrote:
>
>
>
> On Mon, Apr 15, 2013 at 7:51 AM, Damian Skrodzki 
>  > wrote:
>
>> Hi,
>>
>> After looking through proposed ideas for the current GSoC i found 2 
>> issues related close to the code quality which I'm interested in. These are:
>>
>>
>>1. Best practices Updates
>>2. Improved error reporting
>>
>> Both tasks are a different but they are very closely related just to code 
>> quality which if very important especially in projects in size of Django 
>> ;). I will try to suggest that maybe merging them into one little bigger 
>> task would be better idea. I'll explainin characteristics of these.
>>
>> Take the second one as a first. This project will require trying to 
>> reproduce some bugs and fix some error handling in order to allow other 
>> developers to fix their bugs more easily. I think that trying to analyse 
>> code, predict all scenarios and write all expected messages seems like 
>> impossible task. It's better to fix tasks already reported by users. So 
>> here comes the list 
>> https://code.djangoproject.com/wiki/BetterErrorMessages. Unfortunately 
>> (or rather fortunately) I found many of the issues from "error handling" 
>> are outdated. On the other side it would be good to review that list and 
>> possibly fix that wrong messages but ... do you think that fixing few error 
>> handlers is enough for 2-month project?
>>
>> The first one will require to know best practices and then rewrite/update 
>> some code to follow them. I think that this could be continuous task, and 
>> the finish of this task if very blurred. Common sense tells me that we 
>> should start with refactoring from "the worst" code then current worst and 
>> keep doing until all project will be up to current best practices. When the 
>> big project is being developed constantly there always be some code that 
>> need refactoring.
>>
>> My idea would be to fix issues from bad "error messages list" which is 
>> definitely achievable and then start to refactoring few functionalities of 
>> Django that very needs it. To make the second part more achievable and 
>> precise, I should choose few particular functionalities the I'd like to 
>> take care of. This approach will allow to fix particular bugs reported by 
>> users. Moreover fixing simpler bugs is usually easier to start with 
>> project. Then having bigger knowledge i could refactor some code.
>>
>>
>> Do you think that it's reachable to do that in described way?
>> Or maybe better stick to the idea of taking just 1 of this projects and 
>> spend some more time on it?
>>
>
> I think that if you do a detailed analysis, you'll find that *both* 
> projects could easily fill a full GSoC semester. 
>
> Take the first project -- the wiki is there as a documented list of known 
> problems, not a comprehensive list of all problems. A comprehensive audit 
> of everywhere that Django internally catches and re-raises exceptions, and 
> how the stack track from those exceptions are exposed, would *easily* 
> consume 12 weeks. 
>
> However, we're not going to accept a project proposal that has a schedule 
> of "audit code for 12 weeks". We're going to need you to do some initial 
> exploration and give us a more detailed list of the sorts of problems 
> you're going to look at.
>
> Yours,
> Russ Magee %-) 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] Improving code quality

[Russell Keith-Magee]

On Mon, Apr 15, 2013 at 7:51 AM, Damian Skrodzki wrote:

> Hi,
>
> After looking through proposed ideas for the current GSoC i found 2 issues
> related close to the code quality which I'm interested in. These are:
>
>
>1. Best practices Updates
>2. Improved error reporting
>
> Both tasks are a different but they are very closely related just to code
> quality which if very important especially in projects in size of Django
> ;). I will try to suggest that maybe merging them into one little bigger
> task would be better idea. I'll explainin characteristics of these.
>
> Take the second one as a first. This project will require trying to
> reproduce some bugs and fix some error handling in order to allow other
> developers to fix their bugs more easily. I think that trying to analyse
> code, predict all scenarios and write all expected messages seems like
> impossible task. It's better to fix tasks already reported by users. So
> here comes the list
> https://code.djangoproject.com/wiki/BetterErrorMessages. Unfortunately
> (or rather fortunately) I found many of the issues from "error handling"
> are outdated. On the other side it would be good to review that list and
> possibly fix that wrong messages but ... do you think that fixing few error
> handlers is enough for 2-month project?
>
> The first one will require to know best practices and then rewrite/update
> some code to follow them. I think that this could be continuous task, and
> the finish of this task if very blurred. Common sense tells me that we
> should start with refactoring from "the worst" code then current worst and
> keep doing until all project will be up to current best practices. When the
> big project is being developed constantly there always be some code that
> need refactoring.
>
> My idea would be to fix issues from bad "error messages list" which is
> definitely achievable and then start to refactoring few functionalities of
> Django that very needs it. To make the second part more achievable and
> precise, I should choose few particular functionalities the I'd like to
> take care of. This approach will allow to fix particular bugs reported by
> users. Moreover fixing simpler bugs is usually easier to start with
> project. Then having bigger knowledge i could refactor some code.
>
>
> Do you think that it's reachable to do that in described way?
> Or maybe better stick to the idea of taking just 1 of this projects and
> spend some more time on it?
>

I think that if you do a detailed analysis, you'll find that *both*
projects could easily fill a full GSoC semester.

Take the first project -- the wiki is there as a documented list of known
problems, not a comprehensive list of all problems. A comprehensive audit
of everywhere that Django internally catches and re-raises exceptions, and
how the stack track from those exceptions are exposed, would *easily*
consume 12 weeks.

However, we're not going to accept a project proposal that has a schedule
of "audit code for 12 weeks". We're going to need you to do some initial
exploration and give us a more detailed list of the sorts of problems
you're going to look at.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[GSoC 2013] Improving code quality

[Damian Skrodzki]

Hi,

After looking through proposed ideas for the current GSoC i found 2 issues 
related close to the code quality which I'm interested in. These are:


   1. Best practices Updates
   2. Improved error reporting
   
Both tasks are a different but they are very closely related just to code 
quality which if very important especially in projects in size of Django 
;). I will try to suggest that maybe merging them into one little bigger 
task would be better idea. I'll explainin characteristics of these.

Take the second one as a first. This project will require trying to 
reproduce some bugs and fix some error handling in order to allow other 
developers to fix their bugs more easily. I think that trying to analyse 
code, predict all scenarios and write all expected messages seems like 
impossible task. It's better to fix tasks already reported by users. So 
here comes the list https://code.djangoproject.com/wiki/BetterErrorMessages. 
Unfortunately 
(or rather fortunately) I found many of the issues from "error handling" 
are outdated. On the other side it would be good to review that list and 
possibly fix that wrong messages but ... do you think that fixing few error 
handlers is enough for 2-month project?

The first one will require to know best practices and then rewrite/update 
some code to follow them. I think that this could be continuous task, and 
the finish of this task if very blurred. Common sense tells me that we 
should start with refactoring from "the worst" code then current worst and 
keep doing until all project will be up to current best practices. When the 
big project is being developed constantly there always be some code that 
need refactoring.

My idea would be to fix issues from bad "error messages list" which is 
definitely achievable and then start to refactoring few functionalities of 
Django that very needs it. To make the second part more achievable and 
precise, I should choose few particular functionalities the I'd like to 
take care of. This approach will allow to fix particular bugs reported by 
users. Moreover fixing simpler bugs is usually easier to start with 
project. Then having bigger knowledge i could refactor some code.


Do you think that it's reachable to do that in described way?
Or maybe better stick to the idea of taking just 1 of this projects and 
spend some more time on it?

If you for example know that there are much work needed with code 
refactoring, maybe it would be better to take precisely this project and 
leave the other. On the other side if there are more places that are 
poorely handled then it could be better to take into consideration this one.

Thanks,
Damian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.