Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Carlton Gibson]

Hi Manav. Great, thanks! 

On Tue, 17 Jan 2023 at 22:26, Manav Agarwal  wrote:

> Hii All!
>
> I am a Google Summer of Code 2021 Student and have contributed to
> The schema editor project.
> I would be happy to mentor a project this year.
>
> On Tue, Jan 17, 2023 at 8:23 PM Carlton Gibson 
> wrote:
>
>> Hi All!
>>
>> Thanks for your earlier replies, comments and ideas!
>>
>> The organisation application period for GSoC begins next week, so I've
>> pulled them together to begin the ideas page:
>>
>> https://code.djangoproject.com/wiki/SummerOfCode2023
>>
>> It's not 100% — not least I need to go over the WIKI formatting, and make
>> it consistent (but ignore that, or make clean ups :)
>> *Please have a look *— see if the descriptions make sense.
>> (I want to add a few more links and such, and tweak the descriptions —
>> again, happy to take edits :)
>>
>> If you suggested an idea I put you as a *Possible Mentor*.
>> That doesn't mean you're committed to anything — but equally we do need
>> mentors… :)
>> What's involved? Not too much: being available to comment on a PR on your
>> project is the main bit.
>> If you know you're not happy to mentor, you can remove yourself: if
>> you're the only person, please put me instead.
>> *(*If you *didn't* suggest an idea but might like mentoring do feel free
>> to do the opposite :)
>>
>> It's Google *Summer *of Code — so there's ages before anything much else
>> happens.
>>
>> Thanks again.
>>
>> Kind Regards,
>>
>> Carlton
>>
>> On Tuesday, 15 November 2022 at 10:11:45 UTC+1 Carlton Gibson wrote:
>>
>>> Hi all.
>>>
>>> Google Summer of Code (GSoC) for 2023 has just been announced.
>>>
>>> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>>>
>>> Django has participated many times, and it's been a real boon. Recent
>>> successes include:
>>>
>>> * The django-stubs mypy plugin.
>>> * The cross-db JSON field.
>>> * The Redis cache backend.
>>> * Per model-class (field instance) custom lookups
>>> * Setup of the django-asv benchmarking project.
>>> * ...
>>>
>>> Application deadline for Orgs is February 7. I'll begin working on it
>>> after the New Year.
>>>
>>> Main bit is an ideas list for projects. The GSoC guide has a Writing a
>>> Good Ideas List
>>> section.
>>>
>>> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
>>> complete.
>>>
>>> i.e. "short" or "long" projects.
>>> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>>>
>>> I'm writing here *to solicit input on project ideas*.
>>>
>>> I put "Technical Board?" in the subject because we're short a list of
>>> project
>>> ideas for the technical direction of Django going forward, and maybe
>>> thinking
>>> in terms of GSoC could be a way of bootstrapping that. The "?" is
>>> because that's not
>>> meant to exclude other input.
>>>
>>> Here's last year's list for reference:
>>> https://code.djangoproject.com/wiki/SummerOfCode2022
>>>
>>> - Some of those were done: benchmarking (but that could be built on) and
>>> per-instance
>>>   field lookups.
>>>
>>> - Rate-limiting is a no-go I think: we couldn't come to any decent
>>> agreement on scope,
>>>   so it's better to live as a third-party package.
>>>
>>> - I've tried to include folks from the wider ecosystem in previous
>>> years. Two years ago
>>>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>>>   applied in their own right, to great success. I'd like to offer that
>>> help
>>>   again to e.g. Jazzband or other established projects, assuming
>>> maintainers
>>>   feel they have the capacity to mentor. (It's a minor increment to my
>>> effort
>>>   for a good return I think.)
>>>
>>>
>>> No urgency but, can I ask you to put your grey cells into action? 
>>>
>>>
>>> Thanks.
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>> --
>> 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/58bf890d-28be-49b2-827e-a7cbe1f9587en%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Regards
> Manav Agarwal
>
> [image: https://www.linkedin.com/in/manav-agarwal-982553190/]
> 
>
> *"If your actions inspire others to dream more, learn more, do more and
> become more, you are a leader.”*
>
> --
> 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 

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Manav Agarwal]

Hii All!

I am a Google Summer of Code 2021 Student and have contributed to
The schema editor project.
I would be happy to mentor a project this year.

On Tue, Jan 17, 2023 at 8:23 PM Carlton Gibson 
wrote:

> Hi All!
>
> Thanks for your earlier replies, comments and ideas!
>
> The organisation application period for GSoC begins next week, so I've
> pulled them together to begin the ideas page:
>
> https://code.djangoproject.com/wiki/SummerOfCode2023
>
> It's not 100% — not least I need to go over the WIKI formatting, and make
> it consistent (but ignore that, or make clean ups :)
> *Please have a look *— see if the descriptions make sense.
> (I want to add a few more links and such, and tweak the descriptions —
> again, happy to take edits :)
>
> If you suggested an idea I put you as a *Possible Mentor*.
> That doesn't mean you're committed to anything — but equally we do need
> mentors… :)
> What's involved? Not too much: being available to comment on a PR on your
> project is the main bit.
> If you know you're not happy to mentor, you can remove yourself: if you're
> the only person, please put me instead.
> *(*If you *didn't* suggest an idea but might like mentoring do feel free
> to do the opposite :)
>
> It's Google *Summer *of Code — so there's ages before anything much else
> happens.
>
> Thanks again.
>
> Kind Regards,
>
> Carlton
>
> On Tuesday, 15 November 2022 at 10:11:45 UTC+1 Carlton Gibson wrote:
>
>> Hi all.
>>
>> Google Summer of Code (GSoC) for 2023 has just been announced.
>>
>> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>>
>> Django has participated many times, and it's been a real boon. Recent
>> successes include:
>>
>> * The django-stubs mypy plugin.
>> * The cross-db JSON field.
>> * The Redis cache backend.
>> * Per model-class (field instance) custom lookups
>> * Setup of the django-asv benchmarking project.
>> * ...
>>
>> Application deadline for Orgs is February 7. I'll begin working on it
>> after the New Year.
>>
>> Main bit is an ideas list for projects. The GSoC guide has a Writing a
>> Good Ideas List
>> section.
>>
>> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
>> complete.
>>
>> i.e. "short" or "long" projects.
>> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>>
>> I'm writing here *to solicit input on project ideas*.
>>
>> I put "Technical Board?" in the subject because we're short a list of
>> project
>> ideas for the technical direction of Django going forward, and maybe
>> thinking
>> in terms of GSoC could be a way of bootstrapping that. The "?" is because
>> that's not
>> meant to exclude other input.
>>
>> Here's last year's list for reference:
>> https://code.djangoproject.com/wiki/SummerOfCode2022
>>
>> - Some of those were done: benchmarking (but that could be built on) and
>> per-instance
>>   field lookups.
>>
>> - Rate-limiting is a no-go I think: we couldn't come to any decent
>> agreement on scope,
>>   so it's better to live as a third-party package.
>>
>> - I've tried to include folks from the wider ecosystem in previous years.
>> Two years ago
>>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>>   applied in their own right, to great success. I'd like to offer that
>> help
>>   again to e.g. Jazzband or other established projects, assuming
>> maintainers
>>   feel they have the capacity to mentor. (It's a minor increment to my
>> effort
>>   for a good return I think.)
>>
>>
>> No urgency but, can I ask you to put your grey cells into action? 
>>
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
> --
> 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/58bf890d-28be-49b2-827e-a7cbe1f9587en%40googlegroups.com
> 
> .
>


-- 
Regards
Manav Agarwal

[image: https://www.linkedin.com/in/manav-agarwal-982553190/]


*"If your actions inspire others to dream more, learn more, do more and
become more, you are a leader.”*

-- 
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/CACbxD0CRGU_Wh_mabK8FBREYwg4TtmCheNc2kcx45K4KATDf6A%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Carlton Gibson]

Hi All! 

Thanks for your earlier replies, comments and ideas!

The organisation application period for GSoC begins next week, so I've 
pulled them together to begin the ideas page: 

https://code.djangoproject.com/wiki/SummerOfCode2023

It's not 100% — not least I need to go over the WIKI formatting, and make 
it consistent (but ignore that, or make clean ups :) 
*Please have a look *— see if the descriptions make sense. 
(I want to add a few more links and such, and tweak the descriptions — 
again, happy to take edits :) 

If you suggested an idea I put you as a *Possible Mentor*. 
That doesn't mean you're committed to anything — but equally we do need 
mentors… :)
What's involved? Not too much: being available to comment on a PR on your 
project is the main bit. 
If you know you're not happy to mentor, you can remove yourself: if you're 
the only person, please put me instead. 
*(*If you *didn't* suggest an idea but might like mentoring do feel free to 
do the opposite :) 

It's Google *Summer *of Code — so there's ages before anything much else 
happens. 

Thanks again. 

Kind Regards,

Carlton

On Tuesday, 15 November 2022 at 10:11:45 UTC+1 Carlton Gibson wrote:

> Hi all. 
>
> Google Summer of Code (GSoC) for 2023 has just been announced. 
>
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Django has participated many times, and it's been a real boon. Recent 
> successes include: 
>
> * The django-stubs mypy plugin. 
> * The cross-db JSON field. 
> * The Redis cache backend. 
> * Per model-class (field instance) custom lookups
> * Setup of the django-asv benchmarking project. 
> * ... 
>
> Application deadline for Orgs is February 7. I'll begin working on it 
> after the New Year. 
>
> Main bit is an ideas list for projects. The GSoC guide has a Writing a 
> Good Ideas List
> section. 
>
> > Projects should take ~175 hours or ~350 hours for GSoC contributors to 
> complete. 
>
> i.e. "short" or "long" projects. 
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> I'm writing here *to solicit input on project ideas*. 
>
> I put "Technical Board?" in the subject because we're short a list of 
> project
> ideas for the technical direction of Django going forward, and maybe 
> thinking
> in terms of GSoC could be a way of bootstrapping that. The "?" is because 
> that's not 
> meant to exclude other input.
>
> Here's last year's list for reference: 
> https://code.djangoproject.com/wiki/SummerOfCode2022
>
> - Some of those were done: benchmarking (but that could be built on) and 
> per-instance 
>   field lookups.
>
> - Rate-limiting is a no-go I think: we couldn't come to any decent 
> agreement on scope, 
>   so it's better to live as a third-party package. 
>
> - I've tried to include folks from the wider ecosystem in previous years. 
> Two years ago 
>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>   applied in their own right, to great success. I'd like to offer that help
>   again to e.g. Jazzband or other established projects, assuming 
> maintainers
>   feel they have the capacity to mentor. (It's a minor increment to my 
> effort
>   for a good return I think.)
>
>
> No urgency but, can I ask you to put your grey cells into action? 
>
>
> Thanks. 
>
> Kind Regards,
>
> Carlton
>

-- 
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/58bf890d-28be-49b2-827e-a7cbe1f9587en%40googlegroups.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Mehfooz Shayan]

Hi Developers, I am a Junior Python / Django Developer. I have developed
some projects with help of Django Backend Development with
complete authentication & authorization and others features.

So now my question is that, I am also learning Flutter in my university
course (Mobile Application Development - Flutter), so can I deploy my ML,
AI model with the help of Django as a Backend and FrontEnd of Mobile
application in Flutter ???

It will be easy or difficult to connect Django + Flutter for AI, ML models?
Any youtube channel or suggestion where i can covers these things so i can
develop my projects.

Thanks

On Tue, Nov 15, 2022 at 2:11 PM Carlton Gibson 
wrote:

> Hi all.
>
> Google Summer of Code (GSoC) for 2023 has just been announced.
>
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Django has participated many times, and it's been a real boon. Recent
> successes include:
>
> * The django-stubs mypy plugin.
> * The cross-db JSON field.
> * The Redis cache backend.
> * Per model-class (field instance) custom lookups
> * Setup of the django-asv benchmarking project.
> * ...
>
> Application deadline for Orgs is February 7. I'll begin working on it
> after the New Year.
>
> Main bit is an ideas list for projects. The GSoC guide has a Writing a
> Good Ideas List
> section.
>
> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
> complete.
>
> i.e. "short" or "long" projects.
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> I'm writing here *to solicit input on project ideas*.
>
> I put "Technical Board?" in the subject because we're short a list of
> project
> ideas for the technical direction of Django going forward, and maybe
> thinking
> in terms of GSoC could be a way of bootstrapping that. The "?" is because
> that's not
> meant to exclude other input.
>
> Here's last year's list for reference:
> https://code.djangoproject.com/wiki/SummerOfCode2022
>
> - Some of those were done: benchmarking (but that could be built on) and
> per-instance
>   field lookups.
>
> - Rate-limiting is a no-go I think: we couldn't come to any decent
> agreement on scope,
>   so it's better to live as a third-party package.
>
> - I've tried to include folks from the wider ecosystem in previous years.
> Two years ago
>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>   applied in their own right, to great success. I'd like to offer that help
>   again to e.g. Jazzband or other established projects, assuming
> maintainers
>   feel they have the capacity to mentor. (It's a minor increment to my
> effort
>   for a good return I think.)
>
>
> No urgency but, can I ask you to put your grey cells into action? 
>
>
> Thanks.
>
> Kind Regards,
>
> Carlton
>
> --
> 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/194b43ff-98cf-4736-8360-3d79e9b62402n%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/CAH5CCcUABMmY%3D%3DqVyoMz6qpawFNa-heus%2BYOko9jb6C18z4PJA%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Ryan Cheley]

Perhaps one of the ideas for GSoC would be to update the code for the ORM 
(or maybe just a single backend?) to include Type hints. Last year (2022) 
it was mentioned here 
.

I think this might make it easier to allow newcomers to try work Trac 
Tickets. When I was working ticket 10070 
 I found myself (on more than 
one occasion) asking, what is this going to return? I was able to hack my 
way through it, but it would have been nice (potentially) have had had 
types in there!

I know that there was a discussion on the Developers list here 
 and here 
 and a proposed 
DEP  that was closed ... the idea 
seems to be more of a 'wait and see'. 

I believe Carlton also referenced the idea of type hints in a couple of 
episodes of Django Chat (e103 with Nikita Sobolev and e105 with Adam 
Johnson)

Current ticket in trac is 29299 


Cheers,

Ryan

On Tuesday, November 29, 2022 at 1:40:41 PM UTC-8 charettes wrote:

> Adrian,
>
> > I'd personally like to see better support for safe / N-1 compatible 
> migrations within Django itself, currently if you do CD / blue-green tower 
> / etc. deployments you need to be very careful about the migration 
> operations that you introduce version-to-version, although I'm not sure 
> what that would look like.
>
> There's a little project that we use at $WORK to do just that[0]. I'm not 
> sure its inclusion in core is even proposable at this time as is still has 
> received very little feedback from external users but the gist of the tool 
> is that it introduces a notion of phases to migrations (pre and 
> post-deployment) and augments the `makemigrations` command so it splits 
> operations that require multiple phases in multiple migrations and adds a 
> `--pre-deploy` 
> flag to the `migrate` command to only run migrations meant to be run prior 
> to a deployment.
>
> I don't want to hijack the this thread to discuss it in details but feel 
> free to try it out and reach out personally if you'd like more details. 
> We've used it internally to deploy changes using ArgoCD to Kubernetes 
> clusters internally and I was planing on presenting the tool in the near 
> future at a Django event once we get more feedback about it.
>
> [0] https://github.com/charettes/django-syzygy
>
> Cheers,
> Simon
> Le mardi 29 novembre 2022 à 04:41:49 UTC-5, ator...@redhat.com a écrit :
>
>> I'd personally like to see better support for safe / N-1 compatible 
>> migrations within Django itself, currently if you do CD / blue-green tower 
>> / etc. deployments you need to be very careful about the migration 
>> operations that you introduce version-to-version, although I'm not sure 
>> what that would look like.
>>
>> +1 to OIDC, CORS and DB defaults
>>
>> If nothing else, this thread has at least made me aware of some 
>> interesting tickets :-)
>>
>> Adrian
>>
>> On Tuesday, November 29, 2022 at 5:35:40 AM UTC+1 Adam Johnson wrote:
>>
>>> I am not sure the db level defaults PR is suitable for a GSoC project at 
>>> this point - it’s pretty well developed. I think it could do with some 
>>> review and testing form those who are interested.
>>>
>>> On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django 
>>> developers (Contributions to Django itself) <
>>> django-d...@googlegroups.com> wrote:
>>>
 +1 from me on DB defaults (constraints too). I've worked on many 
 systems where Django isn't the only place putting records into DBs and 
 having DB level defaults and constraints fixes a lot of common issues with 
 that. Currently I create an empty migrations to then add them in manually 
 when required


 +1 from me on moving models between apps, though I know it can be a 
 pain. Contacting and freelancing means you come across a lot of projects 
 where models are seeming in the wrong app or where you want to consolidate 
 apps and being able to move them cleaning would be a wonderful addition
 On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:

> I'd like to see database-level defaults supported in models and 
> migrations:
>
> https://code.djangoproject.com/ticket/470
>
> There's currently a PR open, which replaces an earlier 2020 PR
>
> https://github.com/django/django/pull/16092
>
> It would be a large benefit to those of us practicing continuous 
> deployment. It is also tricky enough that it would benefit from a 
> full-time 
> effort to implement and refactor.
>
> - John
>
> On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson  
> wrote:
>
>> Hi all. 
>>
>> Google Summer of Code (GSoC) for 2023 has just been announced. 

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[charettes]

Adrian,

> I'd personally like to see better support for safe / N-1 compatible 
migrations within Django itself, currently if you do CD / blue-green tower 
/ etc. deployments you need to be very careful about the migration 
operations that you introduce version-to-version, although I'm not sure 
what that would look like.

There's a little project that we use at $WORK to do just that[0]. I'm not 
sure its inclusion in core is even proposable at this time as is still has 
received very little feedback from external users but the gist of the tool 
is that it introduces a notion of phases to migrations (pre and 
post-deployment) and augments the `makemigrations` command so it splits 
operations that require multiple phases in multiple migrations and adds a 
`--pre-deploy` 
flag to the `migrate` command to only run migrations meant to be run prior 
to a deployment.

I don't want to hijack the this thread to discuss it in details but feel 
free to try it out and reach out personally if you'd like more details. 
We've used it internally to deploy changes using ArgoCD to Kubernetes 
clusters internally and I was planing on presenting the tool in the near 
future at a Django event once we get more feedback about it.

[0] https://github.com/charettes/django-syzygy

Cheers,
Simon
Le mardi 29 novembre 2022 à 04:41:49 UTC-5, ator...@redhat.com a écrit :

> I'd personally like to see better support for safe / N-1 compatible 
> migrations within Django itself, currently if you do CD / blue-green tower 
> / etc. deployments you need to be very careful about the migration 
> operations that you introduce version-to-version, although I'm not sure 
> what that would look like.
>
> +1 to OIDC, CORS and DB defaults
>
> If nothing else, this thread has at least made me aware of some 
> interesting tickets :-)
>
> Adrian
>
> On Tuesday, November 29, 2022 at 5:35:40 AM UTC+1 Adam Johnson wrote:
>
>> I am not sure the db level defaults PR is suitable for a GSoC project at 
>> this point - it’s pretty well developed. I think it could do with some 
>> review and testing form those who are interested.
>>
>> On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django 
>> developers (Contributions to Django itself)  
>> wrote:
>>
>>> +1 from me on DB defaults (constraints too). I've worked on many systems 
>>> where Django isn't the only place putting records into DBs and having DB 
>>> level defaults and constraints fixes a lot of common issues with that. 
>>> Currently I create an empty migrations to then add them in manually when 
>>> required
>>>
>>>
>>> +1 from me on moving models between apps, though I know it can be a 
>>> pain. Contacting and freelancing means you come across a lot of projects 
>>> where models are seeming in the wrong app or where you want to consolidate 
>>> apps and being able to move them cleaning would be a wonderful addition
>>> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:
>>>
 I'd like to see database-level defaults supported in models and 
 migrations:

 https://code.djangoproject.com/ticket/470

 There's currently a PR open, which replaces an earlier 2020 PR

 https://github.com/django/django/pull/16092

 It would be a large benefit to those of us practicing continuous 
 deployment. It is also tricky enough that it would benefit from a 
 full-time 
 effort to implement and refactor.

 - John

 On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson  
 wrote:

> Hi all. 
>
> Google Summer of Code (GSoC) for 2023 has just been announced. 
>
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Django has participated many times, and it's been a real boon. Recent 
> successes include: 
>
> * The django-stubs mypy plugin. 
> * The cross-db JSON field. 
> * The Redis cache backend. 
> * Per model-class (field instance) custom lookups
> * Setup of the django-asv benchmarking project. 
> * ... 
>
> Application deadline for Orgs is February 7. I'll begin working on it 
> after the New Year. 
>
> Main bit is an ideas list for projects. The GSoC guide has a Writing a 
> Good Ideas List
> section. 
>
> > Projects should take ~175 hours or ~350 hours for GSoC contributors 
> to complete. 
>
> i.e. "short" or "long" projects. 
>
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> I'm writing here *to solicit input on project ideas*. 
>
> I put "Technical Board?" in the subject because we're short a list of 
> project
> ideas for the technical direction of Django going forward, and maybe 
> thinking
> in terms of GSoC could be a way of bootstrapping that. The "?" is 
> because that's not 
> meant to exclude other input.
>
> Here's last year's list for reference: 
> 

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Adrian Torres]

I'd personally like to see better support for safe / N-1 compatible 
migrations within Django itself, currently if you do CD / blue-green tower 
/ etc. deployments you need to be very careful about the migration 
operations that you introduce version-to-version, although I'm not sure 
what that would look like.

+1 to OIDC, CORS and DB defaults

If nothing else, this thread has at least made me aware of some interesting 
tickets :-)

Adrian

On Tuesday, November 29, 2022 at 5:35:40 AM UTC+1 Adam Johnson wrote:

> I am not sure the db level defaults PR is suitable for a GSoC project at 
> this point - it’s pretty well developed. I think it could do with some 
> review and testing form those who are interested.
>
> On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django 
> developers (Contributions to Django itself)  
> wrote:
>
>> +1 from me on DB defaults (constraints too). I've worked on many systems 
>> where Django isn't the only place putting records into DBs and having DB 
>> level defaults and constraints fixes a lot of common issues with that. 
>> Currently I create an empty migrations to then add them in manually when 
>> required
>>
>>
>> +1 from me on moving models between apps, though I know it can be a pain. 
>> Contacting and freelancing means you come across a lot of projects where 
>> models are seeming in the wrong app or where you want to consolidate apps 
>> and being able to move them cleaning would be a wonderful addition
>> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:
>>
>>> I'd like to see database-level defaults supported in models and 
>>> migrations:
>>>
>>> https://code.djangoproject.com/ticket/470
>>>
>>> There's currently a PR open, which replaces an earlier 2020 PR
>>>
>>> https://github.com/django/django/pull/16092
>>>
>>> It would be a large benefit to those of us practicing continuous 
>>> deployment. It is also tricky enough that it would benefit from a full-time 
>>> effort to implement and refactor.
>>>
>>> - John
>>>
>>> On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson  
>>> wrote:
>>>
 Hi all. 

 Google Summer of Code (GSoC) for 2023 has just been announced. 

 https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html

 Django has participated many times, and it's been a real boon. Recent 
 successes include: 

 * The django-stubs mypy plugin. 
 * The cross-db JSON field. 
 * The Redis cache backend. 
 * Per model-class (field instance) custom lookups
 * Setup of the django-asv benchmarking project. 
 * ... 

 Application deadline for Orgs is February 7. I'll begin working on it 
 after the New Year. 

 Main bit is an ideas list for projects. The GSoC guide has a Writing a 
 Good Ideas List
 section. 

 > Projects should take ~175 hours or ~350 hours for GSoC contributors 
 to complete. 

 i.e. "short" or "long" projects. 
 https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

 I'm writing here *to solicit input on project ideas*. 

 I put "Technical Board?" in the subject because we're short a list of 
 project
 ideas for the technical direction of Django going forward, and maybe 
 thinking
 in terms of GSoC could be a way of bootstrapping that. The "?" is 
 because that's not 
 meant to exclude other input.

 Here's last year's list for reference: 
 https://code.djangoproject.com/wiki/SummerOfCode2022

 - Some of those were done: benchmarking (but that could be built on) 
 and per-instance 
   field lookups.

 - Rate-limiting is a no-go I think: we couldn't come to any decent 
 agreement on scope, 
   so it's better to live as a third-party package. 

 - I've tried to include folks from the wider ecosystem in previous 
 years. Two years ago 
   we had both Wagtail and django-stubs projects. Wagtail then (last 
 year)
   applied in their own right, to great success. I'd like to offer that 
 help
   again to e.g. Jazzband or other established projects, assuming 
 maintainers
   feel they have the capacity to mentor. (It's a minor increment to my 
 effort
   for a good return I think.)


 No urgency but, can I ask you to put your grey cells into action? 


 Thanks. 

 Kind Regards,

 Carlton

 -- 

>>> 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-develop...@googlegroups.com.

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com
  
 

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

['Adam Johnson' via Django developers (Contributions to Django itself)]

I am not sure the db level defaults PR is suitable for a GSoC project at
this point - it’s pretty well developed. I think it could do with some
review and testing form those who are interested.

On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django itself) <
django-developers@googlegroups.com> wrote:

> +1 from me on DB defaults (constraints too). I've worked on many systems
> where Django isn't the only place putting records into DBs and having DB
> level defaults and constraints fixes a lot of common issues with that.
> Currently I create an empty migrations to then add them in manually when
> required
>
>
> +1 from me on moving models between apps, though I know it can be a pain.
> Contacting and freelancing means you come across a lot of projects where
> models are seeming in the wrong app or where you want to consolidate apps
> and being able to move them cleaning would be a wonderful addition
> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:
>
>> I'd like to see database-level defaults supported in models and
>> migrations:
>>
>> https://code.djangoproject.com/ticket/470
>>
>> There's currently a PR open, which replaces an earlier 2020 PR
>>
>> https://github.com/django/django/pull/16092
>>
>> It would be a large benefit to those of us practicing continuous
>> deployment. It is also tricky enough that it would benefit from a full-time
>> effort to implement and refactor.
>>
>> - John
>>
>> On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson 
>> wrote:
>>
>>> Hi all.
>>>
>>> Google Summer of Code (GSoC) for 2023 has just been announced.
>>>
>>> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>>>
>>> Django has participated many times, and it's been a real boon. Recent
>>> successes include:
>>>
>>> * The django-stubs mypy plugin.
>>> * The cross-db JSON field.
>>> * The Redis cache backend.
>>> * Per model-class (field instance) custom lookups
>>> * Setup of the django-asv benchmarking project.
>>> * ...
>>>
>>> Application deadline for Orgs is February 7. I'll begin working on it
>>> after the New Year.
>>>
>>> Main bit is an ideas list for projects. The GSoC guide has a Writing a
>>> Good Ideas List
>>> section.
>>>
>>> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
>>> complete.
>>>
>>> i.e. "short" or "long" projects.
>>> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>>>
>>> I'm writing here *to solicit input on project ideas*.
>>>
>>> I put "Technical Board?" in the subject because we're short a list of
>>> project
>>> ideas for the technical direction of Django going forward, and maybe
>>> thinking
>>> in terms of GSoC could be a way of bootstrapping that. The "?" is
>>> because that's not
>>> meant to exclude other input.
>>>
>>> Here's last year's list for reference:
>>> https://code.djangoproject.com/wiki/SummerOfCode2022
>>>
>>> - Some of those were done: benchmarking (but that could be built on) and
>>> per-instance
>>>   field lookups.
>>>
>>> - Rate-limiting is a no-go I think: we couldn't come to any decent
>>> agreement on scope,
>>>   so it's better to live as a third-party package.
>>>
>>> - I've tried to include folks from the wider ecosystem in previous
>>> years. Two years ago
>>>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>>>   applied in their own right, to great success. I'd like to offer that
>>> help
>>>   again to e.g. Jazzband or other established projects, assuming
>>> maintainers
>>>   feel they have the capacity to mentor. (It's a minor increment to my
>>> effort
>>>   for a good return I think.)
>>>
>>>
>>> No urgency but, can I ask you to put your grey cells into action? 
>>>
>>>
>>> Thanks.
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>> --
>>>
>> 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-develop...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/194b43ff-98cf-4736-8360-3d79e9b62402n%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/91e944b1-98cd-4e5e-80e2-f0bad0874f93n%40googlegroups.com
> 
> 

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Carlton Gibson]

On this vein I'd also like to see DB Cascades implemented
https://code.djangoproject.com/ticket/21961


On Mon, 28 Nov 2022 at 18:10, 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django itself) <
django-developers@googlegroups.com> wrote:

> +1 from me on DB defaults (constraints too). I've worked on many systems
> where Django isn't the only place putting records into DBs and having DB
> level defaults and constraints fixes a lot of common issues with that.
> Currently I create an empty migrations to then add them in manually when
> required
>
> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:
>
>> I'd like to see database-level defaults supported in models and
>> migrations:
>>
>> https://code.djangoproject.com/ticket/470
>>
>

-- 
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/CAJwKpyTqhMv6GATZ_wjMpv2YS%3D0aUV%3DNViAZRoi1KBRpePnwBg%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

['st...@jigsawtech.co.uk' via Django developers (Contributions to Django itself)]

+1 from me on DB defaults (constraints too). I've worked on many systems 
where Django isn't the only place putting records into DBs and having DB 
level defaults and constraints fixes a lot of common issues with that. 
Currently I create an empty migrations to then add them in manually when 
required


+1 from me on moving models between apps, though I know it can be a pain. 
Contacting and freelancing means you come across a lot of projects where 
models are seeming in the wrong app or where you want to consolidate apps 
and being able to move them cleaning would be a wonderful addition
On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:

> I'd like to see database-level defaults supported in models and migrations:
>
> https://code.djangoproject.com/ticket/470
>
> There's currently a PR open, which replaces an earlier 2020 PR
>
> https://github.com/django/django/pull/16092
>
> It would be a large benefit to those of us practicing continuous 
> deployment. It is also tricky enough that it would benefit from a full-time 
> effort to implement and refactor.
>
> - John
>
> On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson  
> wrote:
>
>> Hi all. 
>>
>> Google Summer of Code (GSoC) for 2023 has just been announced. 
>>
>> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>>
>> Django has participated many times, and it's been a real boon. Recent 
>> successes include: 
>>
>> * The django-stubs mypy plugin. 
>> * The cross-db JSON field. 
>> * The Redis cache backend. 
>> * Per model-class (field instance) custom lookups
>> * Setup of the django-asv benchmarking project. 
>> * ... 
>>
>> Application deadline for Orgs is February 7. I'll begin working on it 
>> after the New Year. 
>>
>> Main bit is an ideas list for projects. The GSoC guide has a Writing a 
>> Good Ideas List
>> section. 
>>
>> > Projects should take ~175 hours or ~350 hours for GSoC contributors to 
>> complete. 
>>
>> i.e. "short" or "long" projects. 
>> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>>
>> I'm writing here *to solicit input on project ideas*. 
>>
>> I put "Technical Board?" in the subject because we're short a list of 
>> project
>> ideas for the technical direction of Django going forward, and maybe 
>> thinking
>> in terms of GSoC could be a way of bootstrapping that. The "?" is because 
>> that's not 
>> meant to exclude other input.
>>
>> Here's last year's list for reference: 
>> https://code.djangoproject.com/wiki/SummerOfCode2022
>>
>> - Some of those were done: benchmarking (but that could be built on) and 
>> per-instance 
>>   field lookups.
>>
>> - Rate-limiting is a no-go I think: we couldn't come to any decent 
>> agreement on scope, 
>>   so it's better to live as a third-party package. 
>>
>> - I've tried to include folks from the wider ecosystem in previous years. 
>> Two years ago 
>>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>>   applied in their own right, to great success. I'd like to offer that 
>> help
>>   again to e.g. Jazzband or other established projects, assuming 
>> maintainers
>>   feel they have the capacity to mentor. (It's a minor increment to my 
>> effort
>>   for a good return I think.)
>>
>>
>> No urgency but, can I ask you to put your grey cells into action? 
>>
>>
>> Thanks. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>> -- 
>>
> 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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/194b43ff-98cf-4736-8360-3d79e9b62402n%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/91e944b1-98cd-4e5e-80e2-f0bad0874f93n%40googlegroups.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

['John Whitlock' via Django developers (Contributions to Django itself)]

I'd like to see database-level defaults supported in models and migrations:

https://code.djangoproject.com/ticket/470

There's currently a PR open, which replaces an earlier 2020 PR

https://github.com/django/django/pull/16092

It would be a large benefit to those of us practicing continuous
deployment. It is also tricky enough that it would benefit from a full-time
effort to implement and refactor.

- John

On Tue, Nov 15, 2022 at 3:11 AM Carlton Gibson 
wrote:

> Hi all.
>
> Google Summer of Code (GSoC) for 2023 has just been announced.
>
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Django has participated many times, and it's been a real boon. Recent
> successes include:
>
> * The django-stubs mypy plugin.
> * The cross-db JSON field.
> * The Redis cache backend.
> * Per model-class (field instance) custom lookups
> * Setup of the django-asv benchmarking project.
> * ...
>
> Application deadline for Orgs is February 7. I'll begin working on it
> after the New Year.
>
> Main bit is an ideas list for projects. The GSoC guide has a Writing a
> Good Ideas List
> section.
>
> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
> complete.
>
> i.e. "short" or "long" projects.
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> I'm writing here *to solicit input on project ideas*.
>
> I put "Technical Board?" in the subject because we're short a list of
> project
> ideas for the technical direction of Django going forward, and maybe
> thinking
> in terms of GSoC could be a way of bootstrapping that. The "?" is because
> that's not
> meant to exclude other input.
>
> Here's last year's list for reference:
> https://code.djangoproject.com/wiki/SummerOfCode2022
>
> - Some of those were done: benchmarking (but that could be built on) and
> per-instance
>   field lookups.
>
> - Rate-limiting is a no-go I think: we couldn't come to any decent
> agreement on scope,
>   so it's better to live as a third-party package.
>
> - I've tried to include folks from the wider ecosystem in previous years.
> Two years ago
>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>   applied in their own right, to great success. I'd like to offer that help
>   again to e.g. Jazzband or other established projects, assuming
> maintainers
>   feel they have the capacity to mentor. (It's a minor increment to my
> effort
>   for a good return I think.)
>
>
> No urgency but, can I ask you to put your grey cells into action? 
>
>
> Thanks.
>
> Kind Regards,
>
> Carlton
>
> --
> 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/194b43ff-98cf-4736-8360-3d79e9b62402n%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/CAJ3y2QR7jg7cHWbTxEv-Pje9%3Dfxp7yiPBRuoxn1hAAX%3D8v0Vdg%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Tom Carrick]

Just a small spinoff idea from Adam's suggestion on django-stubs. There is
another package, django-types that started as a fork of django-stubs and
was originally intended to be merged back into it. It removes the need to
use any mypy plugins, making it possible to use type checkers other than
mypy, such as Pyrite, Pyre, etc.  However, django-types isn't nearly as
actively maintained and having competing type stubs libraries is quite
annoying as they each get fixes for different issues, leaving neither in
especially good shape, IMO. Although the work has previously been done I
think there is enough work there detangling it and getting a PR to a
mergeable state for a short project.

Tom


On Sat, 26 Nov 2022 at 17:02, Shai Berger  wrote:

> Hi,
>
> Adding to the above, I have two migration-related ideas.
>
> The first is quite down-to-earth: Support for moving models between
> apps. This is a long-standing problem, esp. in enterprise-y or just
> long-running projects. I have expressed my dissatisfaction with the
> current state of things a couple of years ago[1], and maybe it's time
> to change that.
>
> The second is a bit of a pie-in-the-sky: Allow auto-detection of custom
> migration operations. The auto-detector has its change-detection mostly
> hard-coded into it[2], and it doesn't seem easy or even possible to
> allow third-party code to intervene. But I dream...
>
> Note: These two are quite independent. Auto-detection of the fact that
> a model has moved between apps is not required, supporting such moves
> with flags to makemigrations or even a dedicated management-command
> would be completely satisfactory as far as I'm concerned.
>
> Thanks,
> Shai.
>
>
> [1] https://forum.djangoproject.com/t/why-do-we-need-apps/827/20
> [2]
> https://github.com/django/django/blob/main/django/db/migrations/autodetector.py#L104
>
> --
> 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/20221126180231.372b01a2.shai%40platonix.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/CAHoz%3DMbM1M26%2BtrKwX7CoAK_VmORNQGLMLCn_WC5vhAP4PuU4g%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Shai Berger]

Hi,

Adding to the above, I have two migration-related ideas.

The first is quite down-to-earth: Support for moving models between
apps. This is a long-standing problem, esp. in enterprise-y or just
long-running projects. I have expressed my dissatisfaction with the
current state of things a couple of years ago[1], and maybe it's time
to change that.

The second is a bit of a pie-in-the-sky: Allow auto-detection of custom
migration operations. The auto-detector has its change-detection mostly
hard-coded into it[2], and it doesn't seem easy or even possible to
allow third-party code to intervene. But I dream...

Note: These two are quite independent. Auto-detection of the fact that
a model has moved between apps is not required, supporting such moves
with flags to makemigrations or even a dedicated management-command
would be completely satisfactory as far as I'm concerned.

Thanks,
Shai.


[1] https://forum.djangoproject.com/t/why-do-we-need-apps/827/20
[2] 
https://github.com/django/django/blob/main/django/db/migrations/autodetector.py#L104

-- 
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/20221126180231.372b01a2.shai%40platonix.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[James Bennett]

On Fri, Nov 25, 2022 at 2:32 PM 'Adam Johnson' via Django developers 1.
CORS in core

>
> django-cors-headers’ implementation is a bit janky, for example it uses a
> regex to filter paths. It also lacks the key ability to set up different
> CORS policies per path. Both of these could be done with a decorator.
>
> I’d like to see a form of CORS support in Django that more closely follows
> the design of the CSRF/clickjacking protection.
>
>> Another option: Content Security Policy support in core. The current
django-csp third-party app isn't necessarily bad, but I'd love to see more
good security tools in Django by default.

(some of this gets back to an old proposal for a consolidated top-level
SECURITY setting that could expand to cover all the tools, but that's
likely out of scope for a GSoC project)

-- 
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/CAL13Cg8zZZizDRvQCKfe4KS_tPS1zOyW-%3DZSQmj0MkZ7EGnGQA%40mail.gmail.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

['Adam Johnson' via Django developers (Contributions to Django itself)]

Four ideas from myself:

1. CORS in core

django-cors-headers’ implementation is a bit janky, for example it uses a
regex to filter paths. It also lacks the key ability to set up different
CORS policies per path. Both of these could be done with a decorator.

I’d like to see a form of CORS support in Django that more closely follows
the design of the CSRF/clickjacking protection.

2. django-stubs strict mode.

The stubs do not currently pass Mypy’s strict mode. Doing so would enable
users to always use strict mode with them, improving type safety. I think
the other maintainers of django-stubs are also interested in this.

3. Better DatabaseCache

Setting up a shared cache backend is nearly always required, as many third
party packages assume the cache works like this (unlike the default
locmemcache which is per process). DatabaseCache is the easiest such cache
backend, not requiring any extra infra and working on shared hosts without
a filesystem. But it could be better.

Django-Mysql has had a much better DB cache backend implementation since
2015:
https://adamj.eu/tech/2015/05/17/building-a-better-databasecache-for-django-on-mysql/
. I’ve never got around to adapting this for postgres/sqlite but it should
be fairly straightforward, mostly some translation of SQL to different
dialects.

It would also be nice to hook the database cache tables into migrations
somehow rather than the current hacky duck typing approach (
https://github.com/django/django/blob/64b3c413da011f55469165256261f406a277e822/django/core/cache/backends/db.py#L12-L28
).

4. Auto-importing shell

One of the most popular features of django-extensions is shell_plus, which
is like 'shell' but auto-imports your models for you. This behaviour would
be great to have in core, with a way to define extra things to import
(perhaps a documented path of subclassing the management command and
overriding a method).

On Wed, Nov 16, 2022 at 7:13 PM Matthew Pava  wrote:

> I’m not on the technical board or of any important part of the Django
> ecosystem at all, but I do have an idea. It would be nice to revamp the
> “name” field in the default user model, perhaps to have one field for the
> name as suggested here from the W3C:
>
> https://www.w3.org/International/questions/qa-personal-names
>
>
>
> I remember reading elsewhere that there were various important reasons
> that prevented Django from making such a change. Perhaps it would be a good
> time to review that? If there is too much controversy for having a name
> field at all, perhaps eliminating it is the way to go and just have a
> username field?
>
>
>
> Of course, this may go hand-in-hand with Florian’s suggestion of using
> OpenID Connect.
>
>
>
> *From:* django-developers@googlegroups.com <
> django-developers@googlegroups.com> *On Behalf Of *Carlton Gibson
> *Sent:* Wednesday, November 16, 2022 12:58 PM
> *To:* django-developers@googlegroups.com
> *Subject:* Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.
>
>
>
> Thanks Florian
>
>
>
> To you and all :) — casting the net wide right now is a good way forward I
> think.
>
> We can scope down for GSoC with some ideas on the table.
>
>
>
> (Don't be shy folks. :)
>
>
>
> Kind Regards,
>
> Carlton
>
>
>
> On Wed, 16 Nov 2022 at 19:52, Florian Apolloner 
> wrote:
>
> I do have ideas but no idea about how viable they are in a GSoC context.
> Nevertheless I will put write them down here, maybe we can find smaller
> scopes if needed and if not, it still serves as a list of things that I'd
> think to be interesting:
>
>
>
>  * Probably my number one since it kinda is a blocker for me: We need a
> connection pool in Django for async to work. That said connection pools are
> hard to get right (
> https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md
> <https://us-east-2.protection.sophos.com?d=github.com=aHR0cHM6Ly9naXRodWIuY29tL2JyZXR0d29vbGRyaWRnZS9IaWthcmlDUC9ibG9iL2Rldi9kb2N1bWVudHMvV2VsY29tZS1Uby1UaGUtSnVuZ2xlLm1k=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=akpaTG95QTFiaE13MFdpSDJab3RPTmRteEdGamVJOGt6eFk2Y1I4dHRYOD0==c7287be4d6014d549d93a7795f9c8969=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg>
> and https://www.psycopg.org/articles/2021/01/17/pool-design/
> <https://us-east-2.protection.sophos.com?d=psycopg.org=aHR0cHM6Ly93d3cucHN5Y29wZy5vcmcvYXJ0aWNsZXMvMjAyMS8wMS8xNy9wb29sLWRlc2lnbi8==NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=QzJ2dzJBalBxWk5PaEtJaW51WkIycFh1Y0hwUmJUVndIQmw0MklwL2paYz0==c7287be4d6014d549d93a7795f9c8969=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg>
> ).
>
>  * Production ready webserver (

RE: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Matthew Pava]

I’m not on the technical board or of any important part of the Django ecosystem 
at all, but I do have an idea. It would be nice to revamp the “name” field in 
the default user model, perhaps to have one field for the name as suggested 
here from the W3C:
https://www.w3.org/International/questions/qa-personal-names

I remember reading elsewhere that there were various important reasons that 
prevented Django from making such a change. Perhaps it would be a good time to 
review that? If there is too much controversy for having a name field at all, 
perhaps eliminating it is the way to go and just have a username field?

Of course, this may go hand-in-hand with Florian’s suggestion of using OpenID 
Connect.

From: django-developers@googlegroups.com  
On Behalf Of Carlton Gibson
Sent: Wednesday, November 16, 2022 12:58 PM
To: django-developers@googlegroups.com
Subject: Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

Thanks Florian

To you and all :) — casting the net wide right now is a good way forward I 
think.
We can scope down for GSoC with some ideas on the table.

(Don't be shy folks. :)

Kind Regards,

Carlton

On Wed, 16 Nov 2022 at 19:52, Florian Apolloner 
mailto:f.apollo...@gmail.com>> wrote:
I do have ideas but no idea about how viable they are in a GSoC context. 
Nevertheless I will put write them down here, maybe we can find smaller scopes 
if needed and if not, it still serves as a list of things that I'd think to be 
interesting:

 * Probably my number one since it kinda is a blocker for me: We need a 
connection pool in Django for async to work. That said connection pools are 
hard to get right ( 
https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md<https://us-east-2.protection.sophos.com?d=github.com=aHR0cHM6Ly9naXRodWIuY29tL2JyZXR0d29vbGRyaWRnZS9IaWthcmlDUC9ibG9iL2Rldi9kb2N1bWVudHMvV2VsY29tZS1Uby1UaGUtSnVuZ2xlLm1k=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=akpaTG95QTFiaE13MFdpSDJab3RPTmRteEdGamVJOGt6eFk2Y1I4dHRYOD0==c7287be4d6014d549d93a7795f9c8969=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg>
 and 
https://www.psycopg.org/articles/2021/01/17/pool-design/<https://us-east-2.protection.sophos.com?d=psycopg.org=aHR0cHM6Ly93d3cucHN5Y29wZy5vcmcvYXJ0aWNsZXMvMjAyMS8wMS8xNy9wb29sLWRlc2lnbi8==NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=QzJ2dzJBalBxWk5PaEtJaW51WkIycFh1Y0hwUmJUVndIQmw0MklwL2paYz0==c7287be4d6014d549d93a7795f9c8969=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg>
 ).
 * Production ready webserver 
(https://groups.google.com/g/django-developers/c/q20_Cxske88<https://us-east-2.protection.sophos.com?d=google.com=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9nL2RqYW5nby1kZXZlbG9wZXJzL2MvcTIwX0N4c2tlODg==NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=d0VlWEVBVDIrSXhWU3lYNFF5dTVCZDlVR0hBZzBVSlBlMk13d29IdTlsUT0==c7287be4d6014d549d93a7795f9c8969=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg>).
 Maybe only focus on a smaller part first, like reading env variables / config 
files.
 * Depending on how far we get with `request.data` in the meantime, maybe put 
the second steps (adjustable parsers etc) in as GSoC project?
 * I haven't talked with anyone about this one yet, so it might be completely 
bonkers: I think openid connect is here to stay for a while and I'd love to see 
first class support in core for it. I am looking at this from an enterprise 
perspective though; I do not expect a user to choose where to login out of many 
options but rather provide a replacement for the default username/password 
login in an enterprise environment. Most solutions there support openid 
connect. Please note that I am not suggesting to support generic OAuth2/SAML 
and whatnot -- there are great 3rd party packages for that already (which also 
include support for openid connect). I'd just love to be able to install 
arbitrary Django projects and point them to the central authentication server.

I hope this provides some ideas to get more ideas rolling :)

Cheers,
Florian


On Tuesday, November 15, 2022 at 10:11:45 AM UTC+1 
carlton...@gmail.com<mailto:carlton...@gmail.com> wrote:
Hi all.

Google Summer of Code (GSoC) for 2023 has just been announced.
https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html<https://us-east-2.protection.sophos.com?d=googleblog.com=aHR0cHM6Ly9vcGVuc291cmNlLmdvb2dsZWJsb2cuY29tLzIwMjIvMTEvZ2V0LXJlYWR5LWZvci1nb29nbGUtc3VtbWVyLW9mLWNvZGUtMjAyMy5odG1s=NWVjN2YxNzUxNGEyNzMxNmMyMGRkZGU1=ZUZSU1l5RjYxaUpvTk1EUTVYMDhtY2thTHhuOGJXay84bFlqM3QrMjZnbz0==c7287be4d6014d549d93a7795f9c8969=AVNPUEhUT0NFTkNSWVBUSVbDWDgkUnpYUq-QXI1H6ilbUkzDFAbnFfJSRiu9YIEkeaURlIFfQ3PcFY5wLbc1TRMYKUlT84SI1MTdfsb4XlRiT6hJR-SoyEMDruMcFXmveg>

Django has participated many times, and it's been a 

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Carlton Gibson]

Thanks Florian

To you and all :) — casting the net wide right now is a good way forward I
think.
We can scope down for GSoC with some ideas on the table.

(Don't be shy folks. :)

Kind Regards,

Carlton

On Wed, 16 Nov 2022 at 19:52, Florian Apolloner 
wrote:

> I do have ideas but no idea about how viable they are in a GSoC context.
> Nevertheless I will put write them down here, maybe we can find smaller
> scopes if needed and if not, it still serves as a list of things that I'd
> think to be interesting:
>
>  * Probably my number one since it kinda is a blocker for me: We need a
> connection pool in Django for async to work. That said connection pools are
> hard to get right (
> https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md
> and https://www.psycopg.org/articles/2021/01/17/pool-design/ ).
>  * Production ready webserver (
> https://groups.google.com/g/django-developers/c/q20_Cxske88). Maybe only
> focus on a smaller part first, like reading env variables / config files.
>  * Depending on how far we get with `request.data` in the meantime, maybe
> put the second steps (adjustable parsers etc) in as GSoC project?
>  * I haven't talked with anyone about this one yet, so it might be
> completely bonkers: I think openid connect is here to stay for a while and
> I'd love to see first class support in core for it. I am looking at this
> from an enterprise perspective though; I do not expect a user to choose
> where to login out of many options but rather provide a replacement for the
> default username/password login in an enterprise environment. Most
> solutions there support openid connect. Please note that I am not
> suggesting to support generic OAuth2/SAML and whatnot -- there are great
> 3rd party packages for that already (which also include support for openid
> connect). I'd just love to be able to install arbitrary Django projects and
> point them to the central authentication server.
>
> I hope this provides some ideas to get more ideas rolling :)
>
> Cheers,
> Florian
>
>
> On Tuesday, November 15, 2022 at 10:11:45 AM UTC+1 carlton...@gmail.com
> wrote:
>
>> Hi all.
>>
>> Google Summer of Code (GSoC) for 2023 has just been announced.
>>
>> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>>
>> Django has participated many times, and it's been a real boon. Recent
>> successes include:
>>
>> * The django-stubs mypy plugin.
>> * The cross-db JSON field.
>> * The Redis cache backend.
>> * Per model-class (field instance) custom lookups
>> * Setup of the django-asv benchmarking project.
>> * ...
>>
>> Application deadline for Orgs is February 7. I'll begin working on it
>> after the New Year.
>>
>> Main bit is an ideas list for projects. The GSoC guide has a Writing a
>> Good Ideas List
>> section.
>>
>> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
>> complete.
>>
>> i.e. "short" or "long" projects.
>> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>>
>> I'm writing here *to solicit input on project ideas*.
>>
>> I put "Technical Board?" in the subject because we're short a list of
>> project
>> ideas for the technical direction of Django going forward, and maybe
>> thinking
>> in terms of GSoC could be a way of bootstrapping that. The "?" is because
>> that's not
>> meant to exclude other input.
>>
>> Here's last year's list for reference:
>> https://code.djangoproject.com/wiki/SummerOfCode2022
>>
>> - Some of those were done: benchmarking (but that could be built on) and
>> per-instance
>>   field lookups.
>>
>> - Rate-limiting is a no-go I think: we couldn't come to any decent
>> agreement on scope,
>>   so it's better to live as a third-party package.
>>
>> - I've tried to include folks from the wider ecosystem in previous years.
>> Two years ago
>>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>>   applied in their own right, to great success. I'd like to offer that
>> help
>>   again to e.g. Jazzband or other established projects, assuming
>> maintainers
>>   feel they have the capacity to mentor. (It's a minor increment to my
>> effort
>>   for a good return I think.)
>>
>>
>> No urgency but, can I ask you to put your grey cells into action? 
>>
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
> --
> 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/2b3650c6-d340-4464-96f2-e6722a8e415an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the 

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Florian Apolloner]

I do have ideas but no idea about how viable they are in a GSoC context. 
Nevertheless I will put write them down here, maybe we can find smaller 
scopes if needed and if not, it still serves as a list of things that I'd 
think to be interesting:

 * Probably my number one since it kinda is a blocker for me: We need a 
connection pool in Django for async to work. That said connection pools are 
hard to get right ( 
https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md
 
and https://www.psycopg.org/articles/2021/01/17/pool-design/ ).
 * Production ready webserver 
(https://groups.google.com/g/django-developers/c/q20_Cxske88). Maybe only 
focus on a smaller part first, like reading env variables / config files.
 * Depending on how far we get with `request.data` in the meantime, maybe 
put the second steps (adjustable parsers etc) in as GSoC project?
 * I haven't talked with anyone about this one yet, so it might be 
completely bonkers: I think openid connect is here to stay for a while and 
I'd love to see first class support in core for it. I am looking at this 
from an enterprise perspective though; I do not expect a user to choose 
where to login out of many options but rather provide a replacement for the 
default username/password login in an enterprise environment. Most 
solutions there support openid connect. Please note that I am not 
suggesting to support generic OAuth2/SAML and whatnot -- there are great 
3rd party packages for that already (which also include support for openid 
connect). I'd just love to be able to install arbitrary Django projects and 
point them to the central authentication server.

I hope this provides some ideas to get more ideas rolling :)

Cheers,
Florian 


On Tuesday, November 15, 2022 at 10:11:45 AM UTC+1 carlton...@gmail.com 
wrote:

> Hi all. 
>
> Google Summer of Code (GSoC) for 2023 has just been announced. 
>
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Django has participated many times, and it's been a real boon. Recent 
> successes include: 
>
> * The django-stubs mypy plugin. 
> * The cross-db JSON field. 
> * The Redis cache backend. 
> * Per model-class (field instance) custom lookups
> * Setup of the django-asv benchmarking project. 
> * ... 
>
> Application deadline for Orgs is February 7. I'll begin working on it 
> after the New Year. 
>
> Main bit is an ideas list for projects. The GSoC guide has a Writing a 
> Good Ideas List
> section. 
>
> > Projects should take ~175 hours or ~350 hours for GSoC contributors to 
> complete. 
>
> i.e. "short" or "long" projects. 
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> I'm writing here *to solicit input on project ideas*. 
>
> I put "Technical Board?" in the subject because we're short a list of 
> project
> ideas for the technical direction of Django going forward, and maybe 
> thinking
> in terms of GSoC could be a way of bootstrapping that. The "?" is because 
> that's not 
> meant to exclude other input.
>
> Here's last year's list for reference: 
> https://code.djangoproject.com/wiki/SummerOfCode2022
>
> - Some of those were done: benchmarking (but that could be built on) and 
> per-instance 
>   field lookups.
>
> - Rate-limiting is a no-go I think: we couldn't come to any decent 
> agreement on scope, 
>   so it's better to live as a third-party package. 
>
> - I've tried to include folks from the wider ecosystem in previous years. 
> Two years ago 
>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>   applied in their own right, to great success. I'd like to offer that help
>   again to e.g. Jazzband or other established projects, assuming 
> maintainers
>   feel they have the capacity to mentor. (It's a minor increment to my 
> effort
>   for a good return I think.)
>
>
> No urgency but, can I ask you to put your grey cells into action? 
>
>
> Thanks. 
>
> Kind Regards,
>
> Carlton
>

-- 
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/2b3650c6-d340-4464-96f2-e6722a8e415an%40googlegroups.com.

[Technical Board?] Project Ideas, and beginning GSoC 2023.

[Carlton Gibson]

Hi all. 

Google Summer of Code (GSoC) for 2023 has just been announced. 
https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html

Django has participated many times, and it's been a real boon. Recent 
successes include: 

* The django-stubs mypy plugin. 
* The cross-db JSON field. 
* The Redis cache backend. 
* Per model-class (field instance) custom lookups
* Setup of the django-asv benchmarking project. 
* ... 

Application deadline for Orgs is February 7. I'll begin working on it after 
the New Year. 

Main bit is an ideas list for projects. The GSoC guide has a Writing a Good 
Ideas List
section. 

> Projects should take ~175 hours or ~350 hours for GSoC contributors to 
complete. 

i.e. "short" or "long" projects. 
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

I'm writing here *to solicit input on project ideas*. 

I put "Technical Board?" in the subject because we're short a list of 
project
ideas for the technical direction of Django going forward, and maybe 
thinking
in terms of GSoC could be a way of bootstrapping that. The "?" is because 
that's not 
meant to exclude other input.

Here's last year's list for reference: 
https://code.djangoproject.com/wiki/SummerOfCode2022

- Some of those were done: benchmarking (but that could be built on) and 
per-instance 
  field lookups.

- Rate-limiting is a no-go I think: we couldn't come to any decent 
agreement on scope, 
  so it's better to live as a third-party package. 

- I've tried to include folks from the wider ecosystem in previous years. 
Two years ago 
  we had both Wagtail and django-stubs projects. Wagtail then (last year)
  applied in their own right, to great success. I'd like to offer that help
  again to e.g. Jazzband or other established projects, assuming maintainers
  feel they have the capacity to mentor. (It's a minor increment to my 
effort
  for a good return I think.)


No urgency but, can I ask you to put your grey cells into action? 


Thanks. 

Kind Regards,

Carlton

-- 
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/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com.