Re: Question regarding a possible bug

[Curtis Maloney]

On 11/23/18 11:10 AM, bernie2004 wrote:

I am pretty but not 100% sure i found a bug in 2.1.2.

Would it be appropriate to post a description of what i think i found to 
this mailing-list before starting a ticket or is there a better place 
for posting things like that?


Opening a ticket directly is fine, so long as it's not a security 
related issue.


The Django Fellows do an excellent job of curating and addressing 
issues, and the Trac helps keep a coherent history of discussion of the bug.


Just go https://code.djangoproject.com/ and follow the instructions :)

--
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/fa97664e-443c-2caa-8a4a-19bbf1bda8b4%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Question regarding a possible bug

[bernie2004]

I am pretty but not 100% sure i found a bug in 2.1.2.

Would it be appropriate to post a description of what i think i found to 
this mailing-list before starting a ticket or is there a better place for 
posting things like that?

--
Bernie

-- 
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/57f72e92-7c93-456f-82e8-ed39474cbd26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Jason Johns]

This is prompted by James Bennet's article yesterday 
 which prompted a 
discussion with a coworker of mine.

I've been using django for a while now, am a mid-level at a company that 
uses django/DRF heavily, and am a regular lurker here because its a great 
way to keep up with the happenings of the project.  That said, this is from 
an outsiders perspective:


   1. The documentation of the framework is top notch, but the sections on 
   contributing and getting up to speed with the framework, how to run it 
   while developing on it, etc are sparse.  The codebase is fairly 
   intimidating when you read a ticket and then try to dig in.  Fortunately, 
   all breakage from my experimentation is private and not public :-).  I feel 
   having a much more thorough documentation/examples of ramping up and 
   getting started would do a great job in reducing some of that intimidation 
   factor.
   2. The fellows, Tim and Carlton, do a great job here in triaging tickets 
   and handling the day to day work of the project.  But I feel the bug 
   tracker is being a significant hindrance to contributors and possible 
   contributors, and when combined with a lack of intuitive methods to find 
   easy picking tickets makes it more difficult to get going from scratch.  I 
   imagine this is something that has been discussed before.
   3. I like the idea James proposed about mergers and releasers.  I would 
   also suggest that mergers be people who have significant experience in 
   specific parts of Django and handle merging of those tickets.  This is 
   similar to how the Linux kernel project is set up, with maintainers 
   responsible for specific segments of the code tree.  It would also be great 
   if these mergers had technical team-lead like skills that can be used to 
   shepherd both new and knowledgeable contributors onward and upward with 
   tickets, knowledge and support.

I personally am going to make more of an effort to get more involved here, 
but I think these three points above would help lower the mental resistance 
of someone that wants to enter the project.  I have to wonder, however, how 
well situated the experienced people here are for spending time getting new 
contributors up to speed.  Onboarding a new developer is a major time 
allocation at companies, much less open source projects that are being 
worked on in ocassional company time/spare time across the world.  What's 
the capacity available, and who is available for what kind of questions?  

-- 
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/6a80dbf4-dcc5-40dc-bca8-11cdcc6e7ab8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Mat Gadd]

Hi all,

I raised a ticket  regarding 
this and was directed here to discuss the topic. The summary is that the 
combination of using click-tracking redirects (which are popular with a 
variety of email providers) with the Django contrib.auth password reset 
views does not work in Safari on macOS and iOS as of the latest major 
versions.

It took me quite a long time to work out what was happening, so I wanted to 
at least raise a ticket where other people might find it, but was also 
hoping to start a discussion around how else the problem could be 
mitigated. An option to disable the internal token redirect might be 
useful, but that then re-opens the token up to being leaked via the 
HTTP_REFERER header.

Regards,
 - Mat

-- 
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/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.