Re: End of extended support for Django 1.11

[Mariusz Felisiak]

No, support of Django 1.11 ends on 1st April.

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/45c5a2f5-5fbd-4eec-b57c-89fc48367449%40googlegroups.com.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[charettes]

Thanks Sanskar, this iteration is much better.

Now that you have a bit more details about your proposed changes breakdown 
I'd give a bit more examples of what a particular operation currently looks 
like now and you plan to change it. For example, you could describe how an 
AlterField operation currently alter the state/database forwards with the 
involved function calls and how you plan to changes things.

Detailing a bit more how the related lookups cache invalidation would be 
busted and populated when a specific operation is performed would go a long 
way to support your proposal.

To summarize, a few examples of what you have in mind and how things would 
interact together would be appreciated. This is a quite a complex problem 
to solve so a solid initial plan and understanding of the problem will make 
a huge difference down the road.

Cheers,
Simon

Le mercredi 25 mars 2020 19:10:40 UTC-4, Sanskar Jaiswal a écrit :
>
> Hey Simon
>
> I have made some changes to the proposal. I kindly request you to take a 
> look at it and give any feedback you can :)
>
> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>
> Kind Regards 
> Sanskar
>
>
>
> On Wed, 25 Mar 2020 at 23:57, charettes > 
> wrote:
>
>> Are you thinking about the Operation.state_forwards logic? I guess it 
>> would make it easier to test state alterations in isolation but I don't 
>> think it's necessary for this already large project.
>>
>> Cheers,
>> Simon
>>
>> Le mercredi 25 mars 2020 06:05:22 UTC-4, Sanskar Jaiswal a écrit :
>>>
>>> Hey Simon
>>>
>>> Just so that I am more clear, is it favourable to move all logic that 
>>> ModelOperations and FieldOperations implement right now to ProjectState and 
>>> ModelState?
>>>
>>> Kind regards
>>> Sanskar
>>>
>>> On Tue, 24 Mar 2020 at 04:20, Sanskar Jaiswal  
>>> wrote:
>>>
 Hey Simon,

 Thank you for your feedback! It helps a lot. I shall look into your 
 doubts right now, and edit my proposal accordingly.

 Kind regards

 Sanskar

 On Tue, Mar 24, 2020 at 3:37 AM charettes  wrote:

> Hello Sanskar,
>
> Thank you for your submission, from a quick look it seems to be 
> heading in the right direction.
>
> Would it be possible to break the large overview section into more 
> granular sections where you describe how you roughly plan to tackle each 
> of 
> the point mention?
>
> I personally have doubts about your desire to make minimal change to 
> the schema editor and offload the logic to database_forwards instead of 
> the 
> other way around. That doesn't seem to be in line with a future 
> deprecation 
> of support for direct model passing. I'd much rather see us move all 
> methods to (project_state, model_state, *other_state, 
> **other_fields_and_flags) signatures and provide helpers to help 
> third-party backends migrate (e.g. a method decorator that renders mode) 
> then embedding logic for both paths in the schema editor and adding 
> schema 
> specific logic to Operation.database_forwards.
>
> Simon
>
> Le lundi 23 mars 2020 12:59:55 UTC-4, Sanskar Jaiswal a écrit :
>>
>> Hey everyone,
>>
>> Here is my proposal for GSoC. My project is based upon making use of 
>> ModelState during the migrated phase of the project, rather than 
>> rendering 
>> fake Models.
>>
>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>>
>> Feedback and criticism is highly appreciated.
>>
>> Thanks!
>> Kind regards
>> Sanskar
>>
> -- 
> 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-d...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe 

Re: GSoC 2020 Proposal for ModelStates in Migrations

[Sanskar Jaiswal]

Hey Simon

I have made some changes to the proposal. I kindly request you to take a
look at it and give any feedback you can :)

https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5

Kind Regards
Sanskar



On Wed, 25 Mar 2020 at 23:57, charettes  wrote:

> Are you thinking about the Operation.state_forwards logic? I guess it
> would make it easier to test state alterations in isolation but I don't
> think it's necessary for this already large project.
>
> Cheers,
> Simon
>
> Le mercredi 25 mars 2020 06:05:22 UTC-4, Sanskar Jaiswal a écrit :
>>
>> Hey Simon
>>
>> Just so that I am more clear, is it favourable to move all logic that
>> ModelOperations and FieldOperations implement right now to ProjectState and
>> ModelState?
>>
>> Kind regards
>> Sanskar
>>
>> On Tue, 24 Mar 2020 at 04:20, Sanskar Jaiswal 
>> wrote:
>>
>>> Hey Simon,
>>>
>>> Thank you for your feedback! It helps a lot. I shall look into your
>>> doubts right now, and edit my proposal accordingly.
>>>
>>> Kind regards
>>>
>>> Sanskar
>>>
>>> On Tue, Mar 24, 2020 at 3:37 AM charettes  wrote:
>>>
 Hello Sanskar,

 Thank you for your submission, from a quick look it seems to be heading
 in the right direction.

 Would it be possible to break the large overview section into more
 granular sections where you describe how you roughly plan to tackle each of
 the point mention?

 I personally have doubts about your desire to make minimal change to
 the schema editor and offload the logic to database_forwards instead of the
 other way around. That doesn't seem to be in line with a future deprecation
 of support for direct model passing. I'd much rather see us move all
 methods to (project_state, model_state, *other_state,
 **other_fields_and_flags) signatures and provide helpers to help
 third-party backends migrate (e.g. a method decorator that renders mode)
 then embedding logic for both paths in the schema editor and adding schema
 specific logic to Operation.database_forwards.

 Simon

 Le lundi 23 mars 2020 12:59:55 UTC-4, Sanskar Jaiswal a écrit :
>
> Hey everyone,
>
> Here is my proposal for GSoC. My project is based upon making use of
> ModelState during the migrated phase of the project, rather than rendering
> fake Models.
>
> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>
> Feedback and criticism is highly appreciated.
>
> Thanks!
> Kind regards
> Sanskar
>
 --
 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-d...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%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/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%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/CACzaa%3DGtC%2BqnUu%3DVfm4zXpL%2BCRqJa8JP0EyREKc7LVJOLzbq-Q%40mail.gmail.com.

End of extended support for Django 1.11

[Daniela Kim]

Hi everyone,

For *end of extended support* of Django 1.11, the Django Roadmap 
 says "until at 
least April 2020" and Django's Supported Versions 
 page says just 
"April 2020". Given the ambiguity here, may I interpret this as the 
extended support will last until the end of April, if not beyond?

Thanks,
Daniela

-- 
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/007d3628-793e-4f49-b1b6-b5d2265adf02%40googlegroups.com.

Re: Discuss ticket 20264: URLValidator should allow underscores in local hostname

[Adam Johnson]

You're right there are two use cases here. It does sound like the pragmatic
approach is to allow underscores in URL's normally, but to preserve the
existing behaviour for those with stricter use cases, like you say.

I can also propose a solution that would still work for both: (deprecate
> and) rename the current class to StrictURLValidator (or
> URLValidatorRFC1034), to still be easily used for the less common scenarios.


This sounds reasonable to me. I'm not sure we'd need the deprecation
period, given we'd only be adding one character to URLValidator. A release
note is typically enough in this situation, but I normally defer to the
fellows for this.

I think that would make Florian happy, although it *has* been seven years
since his closing comment on the ticket.

On Tue, 24 Mar 2020 at 16:41, Pavel Savchenko  wrote:

> Hey folks,
>
> Sorry for not providing a more specific scenario before, was short on time
> and just wanted to kick this off.
>
> The most common scenario that I can think of (and the one that most
> similar to our usage) would be a *form field* on a Django site, that
> allows users to input a URL which is saved and later displayed *as a link
> to* other users (e.g in blogs, comments, CMS systems, etc).
>
> Here's an example of a site, though clearly not a very reputable one:
> http://online_casino_news.hundredpercentgambling.com/ . Note that google
> groups automatically converted this one to a URL for me, and I was able to
> click and follow it both on Chrome and Firefox.
>
> In the above use case, by validating the correctness of the URL, we
> protect a user from making a mistake, but we don't really care about
> adhering to standards beyond that, the usability wins.
>
> There are other use cases, that might care about RFC 952
> /1034
>  guidelines about
> hostname. For example, if we're building a hosting or a name server
> management system, or maybe SSL certificates vendor.
> In such cases, it might actually benefit the user if the platform alerts
> on the validity of the hostname chosen by the user (at the very least to
> advise the users).
>
> However, I would guess that the first use case, of taking a URL to store
> and render it as a link, would be more common and thus more frequently
> needing to override the class.
>
> I can also propose a solution that would still work for both: (deprecate
> and) rename the current class to StrictURLValidator (or
> URLValidatorRFC1034), to still be easily used for the less common scenarios.
>
> What do you think?
>
> Best Regards,
> Pavel
>
>
> On Tuesday, March 24, 2020 at 2:36:33 PM UTC+1, Adam Johnson wrote:
>>
>> Hi Pavel
>>
>> The ticket ( https://code.djangoproject.com/ticket/20264 ) doesn't
>> mention any specific use cases, and nor have you. What has this behaviour
>> blocked for you?
>>
>> Thanks,
>>
>> Adam
>>
>> On Tue, 24 Mar 2020 at 12:46, Pavel Savchenko  wrote:
>>
>>> Hi Folks,
>>>
>>> I've just encountered this issue, and it seems Django's URLValidator
>>> regex for host is trying to abide to RFC 1034 recommendation
>>>  , when there are many
>>> sites in the wild that use underscore in their domain name.
>>>
>>> Can we please discuss this issue here, so we can eventually decide to
>>> reopen the ticket (or not) and perhaps allow for a pull-request to fix it?
>>>
>>> I found this stackoverflow question helpful, with many answers/comments
>>> with additional references:
>>> https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it
>>>
>>> Best regards,
>>> Pavel
>>>
>>> --
>>> 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-d...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/6982245f-2b5a-4a32-8fe5-a063c7459b7c%40googlegroups.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Adam
>>
> --
> 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/2506854e-9566-444a-8f83-e227215613ea%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 

Re: GSoC 2020 Proposal for ModelStates in Migrations

[charettes]

Are you thinking about the Operation.state_forwards logic? I guess it would 
make it easier to test state alterations in isolation but I don't think 
it's necessary for this already large project.

Cheers,
Simon

Le mercredi 25 mars 2020 06:05:22 UTC-4, Sanskar Jaiswal a écrit :
>
> Hey Simon
>
> Just so that I am more clear, is it favourable to move all logic that 
> ModelOperations and FieldOperations implement right now to ProjectState and 
> ModelState?
>
> Kind regards
> Sanskar
>
> On Tue, 24 Mar 2020 at 04:20, Sanskar Jaiswal  > wrote:
>
>> Hey Simon,
>>
>> Thank you for your feedback! It helps a lot. I shall look into your 
>> doubts right now, and edit my proposal accordingly.
>>
>> Kind regards
>>
>> Sanskar
>>
>> On Tue, Mar 24, 2020 at 3:37 AM charettes > > wrote:
>>
>>> Hello Sanskar,
>>>
>>> Thank you for your submission, from a quick look it seems to be heading 
>>> in the right direction.
>>>
>>> Would it be possible to break the large overview section into more 
>>> granular sections where you describe how you roughly plan to tackle each of 
>>> the point mention?
>>>
>>> I personally have doubts about your desire to make minimal change to the 
>>> schema editor and offload the logic to database_forwards instead of the 
>>> other way around. That doesn't seem to be in line with a future deprecation 
>>> of support for direct model passing. I'd much rather see us move all 
>>> methods to (project_state, model_state, *other_state, 
>>> **other_fields_and_flags) signatures and provide helpers to help 
>>> third-party backends migrate (e.g. a method decorator that renders mode) 
>>> then embedding logic for both paths in the schema editor and adding schema 
>>> specific logic to Operation.database_forwards.
>>>
>>> Simon
>>>
>>> Le lundi 23 mars 2020 12:59:55 UTC-4, Sanskar Jaiswal a écrit :

 Hey everyone,

 Here is my proposal for GSoC. My project is based upon making use of 
 ModelState during the migrated phase of the project, rather than rendering 
 fake Models.

 https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5

 Feedback and criticism is highly appreciated.

 Thanks!
 Kind regards
 Sanskar

>>> -- 
>>> 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-d...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%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/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com.

Re: GSoC Mentors

[charettes]

I confirm my willingness to be a mentor for ORM and Migrations related work.

Simon

Le mercredi 25 mars 2020 04:43:49 UTC-4, Carlton Gibson a écrit :
>
> Hi all. 
>
> We're reaching the end of the application period for GSoC. 
>
> In order to know how many students we might accept, we need to know how 
> many prospective mentors we have. 
>
> This falls into two kinds of job: 
>
> 1. General project management help: communicating with students to help 
> them set a schedule and a rhythm, and make sure they're able to make 
> progress. (The hope is they're self motivated but...) 
>
> 2. More technical input. For this I'm thinking particularly about the 
> migrations framwork (Markus, Simon, Shai, Andrew, ...) but *experienced 
> hands* with knowledge of the internals: your input would be invaluable 
> here. 
>
> The forum seems to be working well, and it's a good format for this kind 
> of thing, so I want to aim to focus the discussion there. 
>
> I'd like to share the mentoring as a group. We'd need to assign specific 
> mentors but I don't see why it can't be a group thing. 
>
> If you could hang out a bit on the forum (mainly for task 1) and/or offer 
> technical input, which you might be doing already/anyway (for task 2) then 
> that would be a super contribution. 
>
> Please let me know if you'd be willing to help mentor. 
>
> 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/4ced51d0-b975-472a-b899-ae4fc4f3e05f%40googlegroups.com.

Re: Automatic prefetching in querysets

[Gordon Wrigley]

My existing code for this is now available as a pypi package
https://github.com/tolomea/django-auto-prefetch 

-- 
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/aaf633e3-a099-4cb4-aad7-10cfe6b11596%40googlegroups.com.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[Sanskar Jaiswal]

Hey Simon

Just so that I am more clear, is it favourable to move all logic that
ModelOperations and FieldOperations implement right now to ProjectState and
ModelState?

Kind regards
Sanskar

On Tue, 24 Mar 2020 at 04:20, Sanskar Jaiswal 
wrote:

> Hey Simon,
>
> Thank you for your feedback! It helps a lot. I shall look into your doubts
> right now, and edit my proposal accordingly.
>
> Kind regards
>
> Sanskar
>
> On Tue, Mar 24, 2020 at 3:37 AM charettes  wrote:
>
>> Hello Sanskar,
>>
>> Thank you for your submission, from a quick look it seems to be heading
>> in the right direction.
>>
>> Would it be possible to break the large overview section into more
>> granular sections where you describe how you roughly plan to tackle each of
>> the point mention?
>>
>> I personally have doubts about your desire to make minimal change to the
>> schema editor and offload the logic to database_forwards instead of the
>> other way around. That doesn't seem to be in line with a future deprecation
>> of support for direct model passing. I'd much rather see us move all
>> methods to (project_state, model_state, *other_state,
>> **other_fields_and_flags) signatures and provide helpers to help
>> third-party backends migrate (e.g. a method decorator that renders mode)
>> then embedding logic for both paths in the schema editor and adding schema
>> specific logic to Operation.database_forwards.
>>
>> Simon
>>
>> Le lundi 23 mars 2020 12:59:55 UTC-4, Sanskar Jaiswal a écrit :
>>>
>>> Hey everyone,
>>>
>>> Here is my proposal for GSoC. My project is based upon making use of
>>> ModelState during the migrated phase of the project, rather than rendering
>>> fake Models.
>>>
>>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>>>
>>> Feedback and criticism is highly appreciated.
>>>
>>> Thanks!
>>> Kind regards
>>> Sanskar
>>>
>> --
>> 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/8e9a5959-d677-456f-9bb8-953e68162562%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/CACzaa%3DFgQASnjxCLeNgbt3nkC8OKSKNH99c3R6Bk%3Dn7Kv6w%3DOQ%40mail.gmail.com.

Re: Proposal for better managed raw SQL migrations

[Petr Přikryl]

Hi Matt,
It looks nice and the idea is very similar to 
https://github.com/festicket/django-migrate-sql. Problems you are noticing 
are same as my. Easy tracking Git changes, code reviews, one place where 
the final definitions live (like models). It would be nice if Django can do 
that.

Petr


Dne středa 25. března 2020 4:49:42 UTC+1 schinckel napsal(a):
>
>
>
> On Wednesday, March 25, 2020 at 1:45:48 AM UTC+10:30, Petr Přikryl wrote:
>>
>> Hi Adam,
>> thank you for your reply.
>>
>> We usually have few indices, functions and triggers. But the most used 
>> database object is view. We used them for data synchronizing from some 
>> third party databases. These databases have complex schema which we want 
>> simplify. So we are building low-level DB API via views. Then we create 
>> Django models for these views. Then is easy to use ORM for data access or 
>> sync operations. 
>>
>>
> Hi Petr,
>
> I too have a bunch of database Raw SQL. I came up with a mechanism for 
> doing this that allows for/generates numbered versions of each file.
>
> https://schinckel.net/2017/06/07/versioning-complex-database-migrations/
>
> There's no way to hook in to the migrations framework to get this to 
> happen during `makemigrations`, but I have used the checks framework to 
> examine the project for any files that appear to be out of date, and moan 
> about those, as well as a custom management command that generates the 
> migrations for any that have changed, as well as the versions.
>
> There's also a command that copies the current version of the file to the 
> "newest" migration which is useful for development.
>
> I'll try to publish the actual code that does it soon.
>
> Matt.
>

-- 
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/f0bbb2e6-123e-48df-bdc8-bc6511aac641%40googlegroups.com.

GSoC Mentors

[Carlton Gibson]

Hi all. 

We're reaching the end of the application period for GSoC. 

In order to know how many students we might accept, we need to know how 
many prospective mentors we have. 

This falls into two kinds of job: 

1. General project management help: communicating with students to help 
them set a schedule and a rhythm, and make sure they're able to make 
progress. (The hope is they're self motivated but...) 

2. More technical input. For this I'm thinking particularly about the 
migrations framwork (Markus, Simon, Shai, Andrew, ...) but *experienced 
hands* with knowledge of the internals: your input would be invaluable 
here. 

The forum seems to be working well, and it's a good format for this kind of 
thing, so I want to aim to focus the discussion there. 

I'd like to share the mentoring as a group. We'd need to assign specific 
mentors but I don't see why it can't be a group thing. 

If you could hang out a bit on the forum (mainly for task 1) and/or offer 
technical input, which you might be doing already/anyway (for task 2) then 
that would be a super contribution. 

Please let me know if you'd be willing to help mentor. 

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/625a8032-f522-49c0-a6c2-8188038a87a5%40googlegroups.com.