Fellow Report - January 2, 2016

[Tim Graham]

A brief update about the Fellowship program: The Django Software Foundation 
needs to have a big fundraising month in January, otherwise the funding 
will be exhausted at the end of the month. As you return to work in the new 
year, please ask your employer to support the DSF if you find this work 
valuable: https://www.djangoproject.com/fundraising/. Thanks!

Triaged

---

https://code.djangoproject.com/ticket/25987 - Creating new object in admin 
with child model inlines and unique_together raises IntegrityError 
(accepted)

https://code.djangoproject.com/ticket/25989 - sitemap view picks lastmod 
from last supplied sitemap only (accepted)

https://code.djangoproject.com/ticket/25878 - APPEND_SLASH doesn't work 
with DEBUG=False when template/404.html is erroneous (accepted)

https://code.djangoproject.com/ticket/25998 - SQLCompiler error when using 
Paginator + values(...) when query returns no data (duplicate)

https://code.djangoproject.com/ticket/25996 - Revise the Performance 
section in topics/http/urls (accepted)

https://code.djangoproject.com/ticket/25997 - Editing ForeignKey in admin 
popup causes incorrect escaping for uuid field (accepted)

https://code.djangoproject.com/ticket/25999 - Document why Django makes its 
deprecation warnings loud by default and how to silence them (created)

https://code.djangoproject.com/ticket/26000 - Error in tutorial05 Django1.9 
(worksforme)

https://code.djangoproject.com/ticket/26001 - Make ModelAdmin.search_fields 
do an integer lookup for IntegerFields (created)

https://code.djangoproject.com/ticket/26002 - Improve 
ModelAdmin.get_search_results() example

https://code.djangoproject.com/ticket/26005 - uri_to_iri() perfoms percent 
decoding incorrectly (accepted)

https://code.djangoproject.com/ticket/26012 - Provide an error message 
during password reset if email doesn't exist (invalid)

https://code.djangoproject.com/ticket/25980 - Disabled 
ModelMultipleChoiceField can't handle querysets as an initial value 
(accepted)

https://code.djangoproject.com/ticket/26020 - Standardize restructed text 
header convention in docs (created)

https://code.djangoproject.com/ticket/26021 - Standardize on hanging indent 
in documentation (created)

Authored



https://github.com/django/django/pull/5885 
 - Fixed #24316 -- Made 
ModelAdmin.list_display callables use an appropriate CSS class name.

https://github.com/django/django/pull/5896 - Refs #13614 -- Added test for 
admin's many-to-many widget data loss bug.

https://github.com/django/django/pull/5888 - Fixed #26003 -- Added "how the 
documentation is organized" section.

https://github.com/django/django/pull/5915 - Fixed #26009 -- Fixed 
contenttypes_tests isolation.

Reviewed/committed

--

https://github.com/django/django/pull/5573 - Fixed #19536 -- Included 
object-tools when ModelAdmin.has_add_permission() is False.

https://github.com/django/django/pull/5875 - Fixed #25465 -- Restored line 
breaks conversion in admin readonly fields.

https://github.com/django/django/pull/5890 - Fixed #26006 -- Fixed 
incorrect object reference in SingleObjectMixin.get_context_object_name().

https://github.com/django/django/pull/5900 - Fixed #26018 -- Prevented 
unecessary get_form() call in FormMixin.get_context_data().

https://github.com/django/django/pull/5905 - Fixed #23372 -- Made loaddata 
faster if it doesn't find any fixtures.

https://github.com/django/django/pull/5895 - Fixed #26011 -- Prevented 
random LiveServerTestCase test failures on Windows.

https://github.com/django/django/pull/5898 - Fixed #26013 -- Moved 
django.core.urlresolvers to django.urls.

https://github.com/django/django/pull/5852 - Fixed #25316 -- Fixed a crash 
with order_by() and values() after annotate().

Reviews of core dev work



https://github.com/django/django/pull/5884 - Moved LogEntry-related tests 
to their own test case

https://github.com/django/django/pull/5879 - Fixed #21113 -- Made 
LogEntry.change_message language independent

https://github.com/django/django/pull/5687 - Fixed #25746 -- Isolated 
inlined test models registration.
https://github.com/django/django/pull/5422 - Fixed #15165 -- Prevented 
wrong results with perimeter on geodetic field.

-- 
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/b0c17505-9f50-4a11-993a-37a90b44d042%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANNOUNCE] Django bugfix releases issued: 1.9.1 and 1.8.8

[Tim Graham]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2016/jan/02/bugfix-releases-issued/

On a related note: Python 3.2 users, please be advised that we've decided 
to drop support for Python 3.2 in Django 1.8.x at the end of 2016. We won't 
break things intentionally after that, but we won't test subsequent 
releases against Python 3.2 either. Upstream support for Python 3.2 ends 
February 2016 so we don't find much value in providing security updates for 
a version of Python that could be insecure. To read more about the decision 
and to let us know if this will be problematic for you, please read the 
django-developers thread: 
https://groups.google.com/d/topic/django-developers/eMu5UQpUdWs/discussion.

-- 
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/20b977e6-1264-4833-b759-079652489534%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Ned Batchelder]

Doug, I'm having a hard time understanding you. You are pointing at data 
and coming to completely different conclusions than I do. Below you say, 
"The Django cadre must regularly ask about the state of public sentiment 
and satisfaction, because it is reckless to do otherwise."  This is 
after you examined the 3000 (!) responses to a survey of the Django 
community. Is there some other way the Django team should ask about 
public sentiment?


You also say, "If the consensus is to deny a need, the documentation 
will continue to be an afterthought," after you yourself noticed that 
the word "documentation" was a prominent answer to, "What's your 
favorite thing about Django?"  Seems like the public has been surveyed, 
and they like the docs.


You've started a discussion here, and in response, people have come up 
with concrete improvements to the docs, and are discussing other ideas.  
But you still seem to be approaching this as if 1) the docs are widely 
regarded as bad, and 2) nothing will be done about it.


Am I missing something?

--Ned.


On 1/1/16 5:35 PM, 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.


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 ongoin

Re: structural & functional review of django documentation

[Aymeric Augustin]

On 2 janv. 2016, at 05:48, Doug Epling  wrote:

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

Hi Doug,

I’m afraid there’s a misunderstanding of how this community operates.

"Team members” — we de-emphazised the “core dev” terminology in 2014 because it 
over-valued writing code — are people who have made consistent, constructive 
contributions to Django, usually starting small and then moving on to more 
ambitious projects. Albeit slow, this process is the best way we have found for 
new contributors to gain trust from existing contributors.

There needs to be some mechanism to give a consistent direction to the Django 
project. Currently we have two layers of decision: community consensus and 
technical board arbitration vote. Obviously voices of team members matter more 
in community discussions. We hope that’s because of their experience with 
Django and the quality of what they say, not just because they carry a “team 
member” flag. Arbitration votes almost never happen. (There was only one, ever, 
to drop support for IE8 from the admin.)

In practice, team members tend to have busy professional lives outside of 
Django. This has stalled many projects in the past. For this reason we 
structured our organization in order to empower community members as much as 
possible and to require as little input from the Django team as possible.

We wouldn’t find a core-only conversation nearly as useful as a community-wide 
discussion. Perhaps that’s why core panels have fallen out of fashion at 
DjangoCons during the last couple of years. And we definitely don’t want 
contributors to censor themselves because of perceived pay grade.

The only pre-requisite to tackling massive projects such as “let’s restructure 
the whole documentation” is to have built enough trust from the current team 
for everyone to know that you will complete it in good conditions. Building 
that trust requires completing successfully small projects, then increasingly 
large ones. Team membership may be offered at some point in that process.

I hope this helps,

-- 
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/2C085DD1-0F56-4ABF-91C7-A3E4D96E345D%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.