Re: Easy Pickings

[Carlton Gibson]

Hi David

I think this is a good idea. The contributing guide says to look for easy
pickings tickets as a good way to get started, but there are hardy any, so
there’s a bit of a disconnect there.

I don’t think there’s any harm in a false positive, so don’t be shy. 😃

Thanks!
C.


On Wed, 10 Feb 2021 at 21:41, smi...@gmail.com  wrote:

> Hi all,
>
> tl;dr - I'm proposing we make more use of the 'easy pickings' flag on trac
> and should aim to have 20-30 tickets with this flag. More options here will
> hopefully help new contributors. If there is support, I'm happy to help
> review tickets to push the number up.
>
>
> I've been thinking about the 'easy pickings' filter and it feels to me
> like a bit of a missed opportunity. As a new contributor, I think filtering
> Trac by this tag is one of the first things I'd do in the hope for an
> 'easy' ticket that is available. Without this we expect folk to pick a
> component and then judge which is 'easy'. I think having somewhat of a
> curated list under this flag could help folk find "easier" tickers. Side
> note: as discussed elsewhere "easy" isn't a great word here, "easier" or
> maybe "ideal first issue" could be better, but is a slightly separate
> topic.
>
> Currently, we have only 8 out of c1,100 tickets marked in this category. I
> think a reasonable target would be for say 20-30 tickets (c.2.0%-2.5%) to
> be in this category. A slightly higher number than now means that there
> would be more chance for folk to pick up an available ticket.
>
> While "easy" is subjective, I think as well as the very rare but obviously
> "easy" tickets (such as re-ordering a list of items in the docs) those
> tickets which are "almost" there (had a prior patch and feedback, and
> "just" need a few tweaks) could fall into this category, as could those
> "just" needing docs. Tickets that have had some thought and work put into
> them, are likely to be far easier than those without.
>
> Appreciate thoughts. I'm more than happy to review some tickets to bump up
> the number.
>
> Thanks
>
> David
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3d87b568-053a-4472-8b93-5d1d377c3820n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyQ7U6tjdg1dQd0Q-jcxCPNoPBCanjDPhYwfuiLxrdgLcg%40mail.gmail.com.

Re: First time contributor, requesting permission to work on #32340

[Surya Banerjee]

Hi Carlton,

I posted my question on the original ticket #32340
 about 10 days ago and still
haven't received any response. I was wondering if there were any particular
norms regarding how long I should wait for a response before starting some
work on the ticket that I should adhere to. Really sorry to bother you with
this, but I am keen to contribute and can't wait to get started.

Thanks,
Surya


On Tue, Feb 2, 2021 at 3:32 PM Surya Banerjee  wrote:

> Hi Carlton,
>
> Thanks for the directions. I have posted my question on the issue tracker.
>
> Thanks,
> Surya
>
> On Tue, Feb 2, 2021 at 1:05 PM Carlton Gibson 
> wrote:
>
>> Hi Surya. Welcome
>>
>> Do comment on the ticket. Thibauld and Tom should be able to give you
>> more specific advice.
>> I'm not sure if Thibauld is already planning work, but there should be
>> room to collaborate.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tuesday, 2 February 2021 at 02:25:10 UTC+1 Surya wrote:
>>
>>>
>>> Hi team,
>>>
>>> I am a new contributor and working with Django as a Junior Developer.
>>> After looking into issue tracker, I see #32340
>>>  as a ticket that I would
>>> love to work on if nobody else is working on it.
>>>
>>> In case I get to work on this, I had a couple of questions regarding
>>> what needs to be done.
>>>
>>> 1. For the suggestion of having explicit instructions on the Django
>>> documentation about the format of the form fields, as described in the
>>> ticket, should I focus on mentioning the default formats for the following
>>> fields -
>>>
>>>- Date and time fields – DateField, DatetimeField, TimeField,
>>>SplitDateTimeField, DurationField
>>>- More technical fields which have very specific formats: SlugField,
>>>JSONField, UUIDField, RegexField, GenericIPAddressField
>>>
>>> 2. Should the changes in the documentation extend to issues such as
>>> #32339  or #32338
>>>  on why it should be
>>> avoided?
>>>
>>> Please forgive me if I have not been able to understand the ticket
>>> responsibility the way it is intended, and I would be very grateful if the
>>> scope of the changes required could be pointed out to me by any senior
>>> member of the community.
>>>
>>> Thanks,
>>> Surya
>>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/4d49125a-61b0-43a7-9698-3ed7e78e6b06n%40googlegroups.com
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABgd%3DVLZrdO_O%3D5juAr_zY5SJ%3DFMKvuwXF4QSRV09j1gz3kqVA%40mail.gmail.com.

Re: First time contributor, requesting permission to work on #32340

[Carlton Gibson]

Hi Surya,

People are busy, especially in the current situation, so sometimes replies
are slow.
But yes, you want to get cracking.

There are a few possible tasks implicit in the ticket there.
One easy and small win was to document the default formats, at least for
the date type fields. How about beginning there? (I need to have a longer
look to know about next steps.)

Thanks! And good hustle. 😃

Kind regards,
Carlton

On Thu, 11 Feb 2021 at 19:33, Surya Banerjee  wrote:

> Hi Carlton,
>
> I posted my question on the original ticket #32340
>  about 10 days ago and still
> haven't received any response. I was wondering if there were any particular
> norms regarding how long I should wait for a response before starting some
> work on the ticket that I should adhere to. Really sorry to bother you with
> this, but I am keen to contribute and can't wait to get started.
>
> Thanks,
> Surya
>
>
> On Tue, Feb 2, 2021 at 3:32 PM Surya Banerjee 
> wrote:
>
>> Hi Carlton,
>>
>> Thanks for the directions. I have posted my question on the issue tracker.
>>
>> Thanks,
>> Surya
>>
>> On Tue, Feb 2, 2021 at 1:05 PM Carlton Gibson 
>> wrote:
>>
>>> Hi Surya. Welcome
>>>
>>> Do comment on the ticket. Thibauld and Tom should be able to give you
>>> more specific advice.
>>> I'm not sure if Thibauld is already planning work, but there should be
>>> room to collaborate.
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>> On Tuesday, 2 February 2021 at 02:25:10 UTC+1 Surya wrote:
>>>

 Hi team,

 I am a new contributor and working with Django as a Junior Developer.
 After looking into issue tracker, I see #32340
  as a ticket that I would
 love to work on if nobody else is working on it.

 In case I get to work on this, I had a couple of questions regarding
 what needs to be done.

 1. For the suggestion of having explicit instructions on the Django
 documentation about the format of the form fields, as described in the
 ticket, should I focus on mentioning the default formats for the following
 fields -

- Date and time fields – DateField, DatetimeField, TimeField,
SplitDateTimeField, DurationField
- More technical fields which have very specific formats:
SlugField, JSONField, UUIDField, RegexField, GenericIPAddressField

 2. Should the changes in the documentation extend to issues such as
 #32339  or #32338
  on why it should be
 avoided?

 Please forgive me if I have not been able to understand the ticket
 responsibility the way it is intended, and I would be very grateful if the
 scope of the changes required could be pointed out to me by any senior
 member of the community.

 Thanks,
 Surya

>>> --
>>> 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 view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/4d49125a-61b0-43a7-9698-3ed7e78e6b06n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/_8rNye7mP7Q/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABgd%3DVLZrdO_O%3D5juAr_zY5SJ%3DFMKvuwXF4QSRV09j1gz3kqVA%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyQ5oY0wic7_0cVbUOv954kxaSMWcXo_aXMowPYLFVbcSw%40mail.gmail.com.

Fellow Reports - February 2021

[Mariusz Felisiak]

Week ending February 7, 2021

Released Django 3.1.6, 3.0.12, and 2.2.18.

*Triaged:*
    https://code.djangoproject.com/ticket/32402 - django.urls resolve 
does not resolve typed paths, like  (invalid)
    https://code.djangoproject.com/ticket/32401 - Email template for 
resetting password is missing the port the application is running on 
(needsinfo)
    https://code.djangoproject.com/ticket/32399 - Allow 
method_decorator() to accept a list/tuple of method names. (wontfix)
    https://code.djangoproject.com/ticket/32404 - Parallel TestRunner 
fails with +1 database replica reference on MacBook Pro. (duplicate)
    https://code.djangoproject.com/ticket/32405 - Inline admin - last 
related item also hidden when user has no add_permission (needsinfo)
    https://code.djangoproject.com/ticket/32403 - When run test with 
off postgres database got `RuntimeError: generator didn't yield` instead 
of connection error (needsinfo)
    https://code.djangoproject.com/ticket/32407 - Add token generator 
for email verification (wontfix)
    https://code.djangoproject.com/ticket/32410 - An empty list is 
considered as an empty value for JSONField. (duplicate)
    https://code.djangoproject.com/ticket/32411 - Case-insensitive 
lookups on JSONField doesn't work on MySQL. (accepted)
    https://code.djangoproject.com/ticket/32415 - Error occurs when 
migrate db: relation is not existed. (invalid)
    https://code.djangoproject.com/ticket/32418 - F() expressions crash 
due to some interval/duration error on MySQL. (duplicate)
    https://code.djangoproject.com/ticket/32414 - Syntax Error when 
combining __in and F() in filter. (duplicate)
    https://code.djangoproject.com/ticket/32421 - Add @cached_property 
in admindocs. (accepted)
    https://code.djangoproject.com/ticket/32423 - Support for extra 
related lookup definitions of a field. (wontfix)
    https://code.djangoproject.com/ticket/32417 - 
LiveServerTestCase._tearDownClassInternal() has unneeded hasattr check 
(accepted)
    https://code.djangoproject.com/ticket/22382 - ManyRelatedManager's 
get_prefetch_queryset doesn't validate the prefetch types (duplicate)


*Reviewed/committed:*
    https://github.com/django/django/pull/13964 - Fixed #32332 -- Fixed 
loss of parent with non-numeric pk when saving child after parent.
    https://github.com/django/django/pull/13952 - Fixed #32395 -- 
Allowed capturing stdout of migration signals.
    https://github.com/django/django/pull/13890 - Fixed #32350 -- Fixed 
showmigrations crash for applied squashed migrations.
    https://github.com/django/django/pull/13975 - Fixed #32420 -- Fixed 
detecting primary key values in deserialization when PK is also a FK.
    https://github.com/django/django/pull/13978 - Fixed #32419 -- 
Clarified URLconf in example of serving media files.
    https://github.com/django/django/pull/13979 - Fixed #32411 -- Fixed 
__icontains lookup for JSONField on MySQL.
    https://github.com/django/django/pull/13951 - Fixed #32394 -- 
Changed project template settings to use relative STATIC_URL.


*Authored:*
    https://github.com/django/django/pull/13963 - Fixed #32403 -- Fixed 
re-raising DatabaseErrors when using only 'postgres' database.
    https://github.com/django/django/pull/13969 - Skipped test_archive 
tests when bz2/lzma module is not installed.


Best,
Mariusz

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/defb7bd3-9833-8e66-a1f9-6e1916cd7d28%40gmail.com.

Getting initial parameters of inline admin model formset using URL

[Manav Agarwal]

We may pass initial Model admin form parameters using URL, visit 
https://docs.djangoproject.com/en/3.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_changeform_initial_data
 
for more details. 
#26607  introduces a hook to 
customize the initial parameters or kwargs for Django admin inline 
formsets. As per the discussion on the ticket and on the respective PR 
, It seems that adding a 
function to initialize formset parameters from the URL would be complex. 
The purpose of starting this discussion is to have some good suggestions to 
implement the same and also to confirm that whether we shall implement such 
function or not.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1a82ee03-4dbd-493e-ad94-6a74165184aan%40googlegroups.com.