On Fri, Apr 19, 2013 at 3:52 AM, Alex Ogier <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
