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 [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.
