Re: structural & functional review of django documentation

[Doug Epling]

Hey Tim --

Basically, we need data.  My recommendation involves two separate initiatives.  

First is, has been, a discussion open for spectators but limited participants 
to core members.  Asside from its subject pertaining current state and future 
path, all other details are above my pay grade.

Second is, has been, the active solicitation of a standardized body of feedback 
from the peripheral users of Django documentation in a fairly substantial 
amount.  We might want to start a new discussion thread on this particular 
topic.

Many thanks for your hard work and dedication. 


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d9f4aa9a-1d9c-4b8b-8e2b-b6c9427b4ce1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Tim Graham]

There weren't any secret discussions among the core team about the data 
from the survey. It helped to inform the roadmap as far as how often a 
Django release should happen, where 6 and 12 months were the most popular 
answers, and we decided on 8 months as a compromise between the two (all of 
this discussion is on this mailing list). Other than that, I don't know 
that it's translated in any actionable results.

I'm happy to support you if you have some specific next steps in mind.

On Friday, January 1, 2016 at 5:35:58 PM UTC-5, Doug Epling wrote:
>
> 
>
> I know some might have hoped I would just go away. But generally speaking 
> when I say I will do something I follow through. At the very least I can 
> work on the Glossary.
>
> I looked at the poll of developers from last May. I loaded the results in 
> an R data.frame, but I did not find any relationships within that data at 
> all. I wonder what conclusions the core team was able to draw from that 
> other than, like, 77 percent of the responses came within 48 hours of its 
> release. This fact must mean something,
>
> Below is a wordcloud representation of the frequency of most used words 
> under the "What's your favorite thing about Django?" item.
>
> This doesn't really mean a lot, but it is kind of neat to look at.
>
> You can notice the prominance of 'documentation', and 'orm'.
>
> Again, these probably don't mean a whole lot, although developer folks 
> sure exhibited an eagerness to express themselves. And you only need to 
> skim over those results to see that a lot of Django regulars, the 
> developers, really like the documentation. It would be interesting to hear 
> why or how these folks use documentation that causes them such affinity for 
> the docs.
>
> Without those why-or-how answers to user interface questions, users 
> defined as extremely active members of the developer community, it is hard 
> to balance with the criticism that pops up here-and-there, including my own.
>
> This discussion begs to transpire among members of the core team because 
> nothing can change unless they see fit. If the consensus is to deny a need, 
> the documentation will continue to be an afterthought.
>
> The Django core developers are not the only public involved. Some might 
> say they are in service to the public at large. The Django cadre must 
> regularly ask about the state of public sentiment and satisfaction, because 
> it is reckless to do otherwise.
>
> [image: Rplot_pos.png]
>
> On Sunday, December 27, 2015 at 5:42:49 PM UTC-5, Tim Graham wrote:
>>
>> Adding a survey link is not difficult. We conducted a community survey 
>> [1] earlier this year with one question related to documentation, "What 
>> parts of the Django documentation do you find most useful?" What questions 
>> to ask and how to turn the answers into actionable items is the part I'm 
>> not sure about and maybe you could advise on.
>>
>> In my view, Django's docs haven't strayed from the "topics", "reference", 
>> and "how-to" division that we've had since 1.0 or so. Are you aware of this 
>> grouping? Maybe a "how the docs are organized" section on the index page 
>> would help communicate that and make it more intuitive where to look for 
>> something?
>>
>> I'll admit I'm skeptical of a wholesale reorganization to this structure 
>> for several reasons:
>> 1. It'll be confusing for existing users who are familiar with the 
>> current section.
>> 2. It'll make it more difficult or impossible to backport documentation 
>> enhancements to the stable version of the docs (assuming we don't also 
>> reorganize them with same structure)
>> 3. It'll create an opportunity for broken links (obviously we could 
>> mitigate this to some extent by adding redirects to the new locations).
>>
>> It seems to me you were pretty close to finding what you were looking for 
>> at https://docs.djangoproject.com/en/1.9/ref/forms/ (first bullet, I 
>> think), but I didn't understand what you meant by the page being "the Joy 
>> of Cooking with Django."
>>
>> [1] https://www.djangoproject.com/weblog/2015/may/07/community-survey/
>>
>> On Sunday, December 27, 2015 at 2:47:35 PM UTC-5, Doug Epling wrote:
>>>
>>> Again, I am sorry if my comments have ruffled anyone's feathers.  I am 
>>> not going to argue.  My sole intent is a positive one.  And, indeed, I am 
>>> humbled by the ongoing work of this community over a period of time that I, 
>>> until now, have not been involved.
>>>
>>> I beleive, it is my impression, that between Django 1.1 and now, on the 
>>> verge of its second major version, there has been a tremendous amount of 
>>> Python software develpment.  And the internal commenting as well as the 
>>> public documentation has trailed along ad hoc.
>>>
>>> It can be said without legitimate reproach that any system whether it is 
>>> thermodynamics or a system of communication, such as our documentation, 
>>> will naturally tend toward entropy unless something 

Re: structural & functional review of django documentation

[Doug Epling]

I know some might have hoped I would just go away. But generally speaking 
when I say I will do something I follow through. At the very least I can 
work on the Glossary.

I looked at the poll of developers from last May. I loaded the results in 
an R data.frame, but I did not find any relationships within that data at 
all. I wonder what conclusions the core team was able to draw from that 
other than, like, 77 percent of the responses came within 48 hours of its 
release. This fact must mean something,

Below is a wordcloud representation of the frequency of most used words 
under the "What's your favorite thing about Django?" item.

This doesn't really mean a lot, but it is kind of neat to look at.

You can notice the prominance of 'documentation', and 'orm'.

Again, these probably don't mean a whole lot, although developer folks sure 
exhibited an eagerness to express themselves. And you only need to skim 
over those results to see that a lot of Django regulars, the developers, 
really like the documentation. It would be interesting to hear why or how 
these folks use documentation that causes them such affinity for the docs.

Without those why-or-how answers to user interface questions, users defined 
as extremely active members of the developer community, it is hard to 
balance with the criticism that pops up here-and-there, including my own.

This discussion begs to transpire among members of the core team because 
nothing can change unless they see fit. If the consensus is to deny a need, 
the documentation will continue to be an afterthought.

The Django core developers are not the only public involved. Some might say 
they are in service to the public at large. The Django cadre must regularly 
ask about the state of public sentiment and satisfaction, because it is 
reckless to do otherwise.

[image: Rplot_pos.png]

On Sunday, December 27, 2015 at 5:42:49 PM UTC-5, Tim Graham wrote:
>
> Adding a survey link is not difficult. We conducted a community survey [1] 
> earlier this year with one question related to documentation, "What parts 
> of the Django documentation do you find most useful?" What questions to ask 
> and how to turn the answers into actionable items is the part I'm not sure 
> about and maybe you could advise on.
>
> In my view, Django's docs haven't strayed from the "topics", "reference", 
> and "how-to" division that we've had since 1.0 or so. Are you aware of this 
> grouping? Maybe a "how the docs are organized" section on the index page 
> would help communicate that and make it more intuitive where to look for 
> something?
>
> I'll admit I'm skeptical of a wholesale reorganization to this structure 
> for several reasons:
> 1. It'll be confusing for existing users who are familiar with the current 
> section.
> 2. It'll make it more difficult or impossible to backport documentation 
> enhancements to the stable version of the docs (assuming we don't also 
> reorganize them with same structure)
> 3. It'll create an opportunity for broken links (obviously we could 
> mitigate this to some extent by adding redirects to the new locations).
>
> It seems to me you were pretty close to finding what you were looking for 
> at https://docs.djangoproject.com/en/1.9/ref/forms/ (first bullet, I 
> think), but I didn't understand what you meant by the page being "the Joy 
> of Cooking with Django."
>
> [1] https://www.djangoproject.com/weblog/2015/may/07/community-survey/
>
> On Sunday, December 27, 2015 at 2:47:35 PM UTC-5, Doug Epling wrote:
>>
>> Again, I am sorry if my comments have ruffled anyone's feathers.  I am 
>> not going to argue.  My sole intent is a positive one.  And, indeed, I am 
>> humbled by the ongoing work of this community over a period of time that I, 
>> until now, have not been involved.
>>
>> I beleive, it is my impression, that between Django 1.1 and now, on the 
>> verge of its second major version, there has been a tremendous amount of 
>> Python software develpment.  And the internal commenting as well as the 
>> public documentation has trailed along ad hoc.
>>
>> It can be said without legitimate reproach that any system whether it is 
>> thermodynamics or a system of communication, such as our documentation, 
>> will naturally tend toward entropy unless something actively intervenes. 
>>  And we have developed a fairly complex system compared to, say, werksgeud. 
>>
>> That patchwork approach has disrupted a flow of utility for users in both 
>> public documentation and internal commenting.  If this is true, Django has 
>> strayed from principles of its foundation.  And our motto: "The framework 
>> for perfectionists with deadlines."; holds true only until fininding 
>> oneself lost in the documentation.
>>
>> Tim is exactly right; this is with no doubt a non-trivial issue.  Is 
>> Django capable of tackling non-trivial issues?  If not I am in the wrong 
>> place (a challenge to Django, relax, it's not personal) because I believe 
>> 

Re: delegating our static file serving

[Aymeric Augustin]

Hello Collin,

> On 31 déc. 2015, at 23:44, Collin Anderson  wrote:
> 
> I feel like the insecure flag could get renamed to inefficient or something 
> like that.

This view is insecure for serving user-uploaded files, for reasons Florian 
hinted at.

Browsers “helpfully” get a lot things wrong for legacy reasons. As a 
consequence,
downloading a file is one of the most insecure things you can do in general.

I can’t say for sure if it’s insecure for serving static files. I believe 
Django has some
countermeasures against directory traversal attacks for example. However, since
the code wasn’t written with security in mind from the beginning, rewriting it 
from a
security perspective may be the most efficient way to make sure it’s secure.

Best regards,

-- 
Aymeric.




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/745A1E1A-AE02-410C-B2B1-705BC08378CC%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Curtis Maloney]

On 01/01/16 15:49, Fabio Caritas Barrionuevo da Luz wrote:

A question: are there any plans to also improve MEDIA files (user
uploaded files) in any foreseeable future?

Perhaps this is outside the scope of Django, but I believe Django could
provide by default, any option to get a little more control over who can
and can not access the MEDIA files.


I certainly agree that at least some basic form of access control ought 
be provided in core/contrib.



Most Django deployment tutorials with Nginx and Apache that saw out
there do not say anything on the issue of data security.

I believe it is a common use case, that not every file sent by a User
should be available and accessible to anyone on the web.


I was talking with Tom Eastman about a related topic at PyConAU this 
year, and I believe the solution is multiple storage engines.


Basically, for each realm of access, have a separate file storage 
instance with its own access policy.


We could then register each storage engine we want published with the 
static/media server machinery, with its associated policy...


Hmm... I think I've just created myself a new project...

--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56864707.5030007%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.