Thank you for your feedback. I really appreciate every comment because that let me improve my proposal.
1. First of all, I noticed that the license of django-secure is copyright. Google forces us to release code under one of approved license [1], so a question to Carl Meyer: do you mind changing license? On a practicality issue, I'd also like to see one more piece of detail in > your "why me" section. Since your from Poland, English is (I'm guessing) a > second language. Your proposal is very clear and shows you have good > communications skills. However, what we don't know is how long it took you > to write this proposal, and how comfortable you are working in English. If > you're not comfortable working in English in "real time" (e.g., on a spoken > phone call, or in IRC), then that will alter the way that you and your > mentor will interact - you may wish to only communicate via email, for > example; and this may slow down the rate of feedback that you can get from > your mentor. > > 2. Last year and this year I attended FCE conversation class, so my English level isn't worse than FCE. I guess that I'm not ready to speak in real time, but I can talk in real time at IRC. But you know, it's hard to judge your own skills. 1. We've had some discussions about bringing django-secure into core > as part of a more general "checkdeploy" command. The idea being > something you can run shortly before deployment that'd check for all > the stuff that django-secure checks for -- but also more (outdated > dependencies, debug mode, exposed admin, etc). I think this dovetails > nicely with your proposal: it seems that all these "checks" > (validation, deployment, security) could use a single discovery and > running mechanism. I'd love to see you think about modifying your > proposal to include this sort of unification as well as the bringing > of django-secure into core. > > 3. I tried to find discussions about the additional functionality expected from django-secure (you mentioned checking outdated dependencies, debug mode and exposed admin), but I didn't succeed. Could you point me to any discussion on this mailing list or in the ticket tracker or anywhere else? I'd possibly add one additional point - the potential for confusion between > validation of the type you're describing, and "model validation". This > isn't a problem of your making - the ambiguity already exists in Django. > However, if we're adding API points on fields, which already support the > idea of "validators", we need to be careful we don't confuse issues more. > To that end, I'd be interested in seeing at least some initial thoughts on > how we can structure the API or change the naming so that this issue is > controlled. > > 4. It looks like changing validate into validate_all solves the problem. We also have to emphasise the difference between those two mechanisms in documentation. 5. I said that I won't have any trip during GSoC, but I forget about my holiday after September 6. This is not backpacking-trip, I will live in a hotel with net access, but I won't be able to work full time. I hope that you won't disqualify my proposal on this basis -- that can be considered as an advantage because I will be highly motivated to finish before time. 6. I've updated my proposal. I'm not repasting it here -- that would be too much mess. If you want to see the new version, look at the gist [2]. Changes to the proposal in short: - *Rewriting the second part of the proposal*. The proposal is not finished, it lacks the "improving django-secure" part. - *Changing schedule of the first half* -- removing "write documentation" week. - *Minor changes.* Changing solution -> hint. Changing validate -> validate_all. Changed app validation rules: the file validation.py won't be created by default for new apps; if the file exists but it misses validate_all or validate_models functions, then the default ones are used. [1] http://opensource.org/licenses/ [2] https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 -- 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.
