Hi Anubhav, I've taken a look at your proposal, and I'm of two minds.
On the one hand, you've identified a bunch of reasonably uncontroversial tickets - issues where there is a clear problem, a solution that seems obvious, and in most cases indications of support from the core team. Your proposal gives a clear indication of what is on your "hit list", and because the work is already nicely granular, your timeline is expressed in units that make it believable. So - from this perspective, you've got a good proposal for a block of work that can be performed in a 12 week window. The problem I have is that other than "squashing bugs", there isn't really a cohesive theme in these tickets. They don't even stick to a single area of the code - you're spread over db. http, core, forms and template. There's two reasons why this matters. The first is theoretical, and the second is practical. Firstly, the theoretical concern: The GSoC is an opportunity to look at something big, not just squash bugs. We've got an opportunity for someone to spend 12 weeks sinking their teeth into something complex. While there's certainly nothing wrong with 12 weeks of fixing little problems, it doesn't really strike me as something that meets the broader aspirations of a program like GSoC. We've been given a great opportunity here; it seems a waste to spend it on lots of little things, however, annoying those little things may be. The practical concern is this: Tackling lots of little tickets is going to be a much higher workload on a potential mentor. Consider - you've listed 17 tickets (from a quick count); each of them describes a different problem. In the worst possible case, each of these tickets may require a detailed discussion on django-developers to discuss the implications of a potential fix. At the very least, there's going to be a lot of disparate review work that your mentor will need to do. This changes the mentor's workload from "weekly guidance and a few small code reviews, and one big code review at the end" to something that requires an almost constant stream of little code reviews. Without these code reviews, your project will essentially stall. Speaking personally, I'd have to consider very carefully before I took on this kind of workload. I appreciate that we've possibly led you down this path by pointing you at the ticket database and saying "find tickets about errors". What we haven't communicated well is that ideally, there should be a common theme. As a point of comparison, here's a commit from about 4 years ago. https://github.com/django/django/commit/c4c27d8a04c9125cfbc5c3611557d8e5d3845b0d This wasn't done as a GSoC project, but it was done by someone who was a student at the time; and it's a good representation of the sort of outcome that I'd like to see. This single commit closed 10 tickets. But it wasn't a matter of fixing 10 little things; Ben identified a systemic set of problem in the syndication framework, and set about fixing the bigger problem. With one commit, it was possible to address all 10 issues - and probably a dozen others that hadn't been reported - because the revised syndication framework was structured so as to avoid these issues. Don't get me wrong - bugs are bad, and it would be nice to have less of them. Many of the bugs you've found relate to the ways that errors manifest as a result of slightly abnormal usage. And your proposal, as written, is solid. If we can find someone willing to mentor it, and we get enough slots, it stands a fair chance of being selected. However, if you're looking for my advice on how to make it stronger and improve your chances -- I'd go looking to see if you can either recast it so that the "common thread" is more obvious (I'm not sure if this is even possible), or take another look at the list of open tickets and try and pick a set that has a slightly more cohesive focus. As one last piece of guidance -- the reason this idea was on the wiki was because there were (at least historically), a bunch of areas where Django would raise errors, but the errors that Django raised were not helpful. This was particularly true during template rendering, and to a lesser extent when import errors occurred during model loading. The idea driving the project was to improve this "grand idea" - making it easier to identify the actual source of the problem. Looking at tickets was suggested as a course of action because when big picture "it's bad" issues exist in a framework, they often get reported in a myriad different ways, each reflecting a subtlety in the bigger problem. The idea wasn't strictly to get you to dig up a bunch of tickets to fix; it was to use the tickets as a roadmap to identifying the "bigger" problem. That said - if someone steps up and volunteers to take on the workload of shepherding lots of smaller, mostly unrelated tickets, I think this project would probably represent a solid contribution to Django. I just know that personally, I'm not going to be able to put my hand up on this one. Yours, Russ Magee %-) On Tue, Mar 11, 2014 at 1:06 AM, anubhav joshi <[email protected]>wrote: > I do keep updating gist upon getting feedback/reviews on IRC as well. > Please keep a track. > https://gist.github.com/coder9042/c505dfba9514a6e52fdc > > > Regards, > Anubhav Joshi > IIT Patna > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/c1d75c1f-f6a7-4d9e-b633-ea467a80aa9c%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/c1d75c1f-f6a7-4d9e-b633-ea467a80aa9c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq848%3DV1xZuipSeGAw18ykHuyTjqUyHYAMd4iuLhCTB3nqZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
