Re: Proposal: Clarify individual members page

[Andrew Mshar]

I like that idea, Tim. A few things came up, so I'll open this PR next week.

Thanks,
Andrew

On Friday, November 11, 2022 at 12:21:43 PM UTC-5 schill...@gmail.com wrote:

> Hi folks!
>
> Andrew (Mshar) how do you feel about reworking:
>
> > If you know someone who you think should be considered for Individual 
> Membership or would like to nominate yourself, please fill out this form 
> 
> .
>
> To something that places more focus on self-nomination, with nominating 
> others as the alternative such as:
>
> If you would like to apply for Individual Membership, please fill out this 
> form. You can also nominate others if you know someone who should be 
> considered.
>
> My reasoning:
>
>- The use of "apply" rather than "nominate yourself". People are used 
>to applying for things for themselves. I imagine fewer nominate themselves 
>for things making it less comfortable. I think using language that's more 
>comfortable will encourage people.
>- Moving the nomination of others to the end highlights that applying 
>for yourself is not the exception flow. Again, this should help encourage 
>people to apply.
>
>
> Thanks for driving this!
>
> On Tue, Nov 8, 2022 at 10:24 PM Andrew Godwin  wrote:
>
>> Just want to pop in and say these are great ideas - feel free to copy me 
>> in on any PR if you want extra opinions!
>>
>> On Tuesday, November 8, 2022 at 8:26:28 AM UTC-7 Carlton Gibson wrote:
>>
>>> Great, Thanks Andrew. No urgency 
>>>
>>> On Tue, 8 Nov 2022 at 16:16, Andrew Mshar  wrote:
>>>
 Will do, Carlton.

 Tim and Cory, thanks for the suggestions. I'll incorporate those in the 
 PR and post here when it's ready. Probably not today, but I should be able 
 to open it before the end of the week.

 Thanks,
 Andrew

 On Tuesday, November 8, 2022 at 10:10:51 AM UTC-5 carlton...@gmail.com 
 wrote:

> Hey Andrew. 
>
> I had thought this was a Flatpage (stored in the database) but it's 
> not. 
> The source is here: 
> https://github.com/django/djangoproject.com/blob/main/djangoproject/templates/members/individualmember_list.html
> If you wanted to open a PR suggesting your changes, that would be 
> amazing 朗
>
> Thanks. 
>
> Kind Regards,
>
> Carlton
>
> On Mon, 7 Nov 2022 at 19:51, Tim Allen  
> wrote:
>
>> I'm of the opinion that if you care enough about Django to 
>> investigate becoming a member of the DSF, that's enough of a 
>> qualification 
>> - it is just challenging to formalize that into proper text for the 
>> website. Maybe two changes to encourage people to join:
>>
>>- We could tweak *"Running Django-related events or user 
>>groups"  *to *"Attending or organizing Django-related events or 
>>user groups"*.
>>- Add a sentence to the end of the first stanza: "The following 
>>are Individual Members of the Django Software Foundation. The DSF 
>> appoints 
>>individual Members in recognition of their service to the Django 
>> community. 
>>If you would like to join the DSF, we welcome you. Please feel free 
>> to 
>>self-nominate for membership."
>>
>> Regards,
>>
>> Tim
>>
>> On Monday, November 7, 2022 at 11:12:41 AM UTC-5 cory...@gmail.com 
>> wrote:
>>
>>> Hey Andrew,
>>>
>>> Thanks for drafting this language and I think it looks great. As 
>>> someone who only recently applied after hearing it discussed on an 
>>> episode 
>>> of Django Chat[1], I'm all for the goals of making it more encouraging 
>>> and 
>>> accessible and think this is a great step in that direction.
>>>
>>> Here are a few minor thoughts to specific bits:
>>>
>>> Service to the Django community takes many forms. Here are some 
 examples (non-exhaustive) of categories of work performed by members:

>>>
>>> "performed by members" is a little ambiguous as to whether it means 
>>> "this is how we evaluate applicants" vs "this is what you'll do if part 
>>> of 
>>> the DSF". Since I think the intention is the former it might make sense 
>>> to 
>>> change to something like:
>>>
>>> *Service to the Django community takes many forms. Here are some 
>>> (non-exhaustive) examples of the categories of work that might qualify 
>>> as 
>>> "service":*
>>>
>>> Borrowed the list of categories from Andrew Godwin's DEP for the 
 update to the technical board. Per Tim's recommendation, do we want to 
 include anything about the review process?

>>>
>>> When I applied I didn't (and still don't, really) have any 
>>> visibility into the process, so it wasn't a deterrent for me, 
>>> personally, 

Re: Proposal: Clarify individual members page

[Tim Schilling]

Hi folks!

Andrew (Mshar) how do you feel about reworking:

> If you know someone who you think should be considered for Individual
Membership or would like to nominate yourself, please fill out this form

.

To something that places more focus on self-nomination, with nominating
others as the alternative such as:

If you would like to apply for Individual Membership, please fill out this
form. You can also nominate others if you know someone who should be
considered.

My reasoning:

   - The use of "apply" rather than "nominate yourself". People are used to
   applying for things for themselves. I imagine fewer nominate themselves for
   things making it less comfortable. I think using language that's more
   comfortable will encourage people.
   - Moving the nomination of others to the end highlights that applying
   for yourself is not the exception flow. Again, this should help encourage
   people to apply.


Thanks for driving this!

On Tue, Nov 8, 2022 at 10:24 PM Andrew Godwin  wrote:

> Just want to pop in and say these are great ideas - feel free to copy me
> in on any PR if you want extra opinions!
>
> On Tuesday, November 8, 2022 at 8:26:28 AM UTC-7 Carlton Gibson wrote:
>
>> Great, Thanks Andrew. No urgency 
>>
>> On Tue, 8 Nov 2022 at 16:16, Andrew Mshar  wrote:
>>
>>> Will do, Carlton.
>>>
>>> Tim and Cory, thanks for the suggestions. I'll incorporate those in the
>>> PR and post here when it's ready. Probably not today, but I should be able
>>> to open it before the end of the week.
>>>
>>> Thanks,
>>> Andrew
>>>
>>> On Tuesday, November 8, 2022 at 10:10:51 AM UTC-5 carlton...@gmail.com
>>> wrote:
>>>
 Hey Andrew.

 I had thought this was a Flatpage (stored in the database) but it's
 not.
 The source is here:
 https://github.com/django/djangoproject.com/blob/main/djangoproject/templates/members/individualmember_list.html
 If you wanted to open a PR suggesting your changes, that would be
 amazing 朗

 Thanks.

 Kind Regards,

 Carlton

 On Mon, 7 Nov 2022 at 19:51, Tim Allen 
 wrote:

> I'm of the opinion that if you care enough about Django to investigate
> becoming a member of the DSF, that's enough of a qualification - it is 
> just
> challenging to formalize that into proper text for the website. Maybe two
> changes to encourage people to join:
>
>- We could tweak *"Running Django-related events or user groups"  *
>to *"Attending or organizing Django-related events or user groups"*
>.
>- Add a sentence to the end of the first stanza: "The following
>are Individual Members of the Django Software Foundation. The DSF 
> appoints
>individual Members in recognition of their service to the Django 
> community.
>If you would like to join the DSF, we welcome you. Please feel free to
>self-nominate for membership."
>
> Regards,
>
> Tim
>
> On Monday, November 7, 2022 at 11:12:41 AM UTC-5 cory...@gmail.com
> wrote:
>
>> Hey Andrew,
>>
>> Thanks for drafting this language and I think it looks great. As
>> someone who only recently applied after hearing it discussed on an 
>> episode
>> of Django Chat[1], I'm all for the goals of making it more encouraging 
>> and
>> accessible and think this is a great step in that direction.
>>
>> Here are a few minor thoughts to specific bits:
>>
>> Service to the Django community takes many forms. Here are some
>>> examples (non-exhaustive) of categories of work performed by members:
>>>
>>
>> "performed by members" is a little ambiguous as to whether it means
>> "this is how we evaluate applicants" vs "this is what you'll do if part 
>> of
>> the DSF". Since I think the intention is the former it might make sense 
>> to
>> change to something like:
>>
>> *Service to the Django community takes many forms. Here are some
>> (non-exhaustive) examples of the categories of work that might qualify as
>> "service":*
>>
>> Borrowed the list of categories from Andrew Godwin's DEP for the
>>> update to the technical board. Per Tim's recommendation, do we want to
>>> include anything about the review process?
>>>
>>
>> When I applied I didn't (and still don't, really) have any visibility
>> into the process, so it wasn't a deterrent for me, personally, but I 
>> think
>> having information certainly wouldn't hurt. My two cents would be good to
>> put something in, but not necessarily if it slows down/stalls this change
>> if for whatever reason that isn't super easy, since I think this 
>> represents
>> an improvement on its own.
>>
>> Also, I'm a little unsure about that last bit about applying, but I

Re: Advancing the "content negotiation" and "modernising request object" proposals.

[charettes]

> DRF’s behaviour feels more correct to me, since it allows terser views 
that don’t check the content type explicitly. But it’s less backwards 
compatible. I’m not sure which I prefer.

Given the .data attribute would be a new feature of the request object I 
assume we don't have any backward compatiblity concerns to worry about as 
long as we document the behaviour of .data properly and leave .POST 
unchanged? I would have a slight preference for raising an 
UnsupportedMediaType as well and letting that percolate to a 415 as it 
seems more correct from a content negotiation perspective.

Le vendredi 11 novembre 2022 à 11:22:44 UTC-5, Adam Johnson a écrit :

> This first-step solution is good with me. It will allow everyone to switch 
> to request.data (etc.). And there’d be a clear way to use your own logic to 
> set request.data if needed: write a middleware (or view decorator, view 
> class, etc.).
>
> What should request.data be/do in the case of an unsupported content type? 
> Currently request.POST returns an empty QueryDict. But DRF raises 
> UnsupportedMediaType if it has no matching parser, which is translated into 
> a 415 Unsupported Media Type response.
>
> DRF’s behaviour feels more correct to me, since it allows terser views 
> that don’t check the content type explicitly. But it’s less backwards 
> compatible. I’m not sure which I prefer.
>
> On Thu, Nov 10, 2022 at 3:14 AM charettes  wrote:
>
>> Hello Carlton,
>>
>> This is not an area of the code base I'm heavily involved with but the 
>> increment approach you are proposing over this lack of feature support for 
>> basic content negotiation seems like a sane approach to gradually make the 
>> landscape better in this area without trying to get everything just right 
>> in a single stab.
>>
>> Adding ``request.data`` with support limited to JSON bodies at first 
>> seems the minimal step to lay some foundations towards revisiting the 
>> inclusion of very core/HTTP centric features that are sadly only available 
>> in DRF at the moment.
>>
>> +1 from me.
>>
>> Cheers,
>> Simon
>>
>> Le mercredi 9 novembre 2022 à 06:32:53 UTC-5, carlton...@gmail.com a 
>> écrit :
>>
>>> Hi all.
>>>
>>> I'm looking for a high-level sanity check if you would. 
>>>
>>> I've been trying to see a way forward through a nest of issues around 
>>> two concrete proposals:
>>>
>>> 1. Adding "content negotiation" to the request object, allowing 
>>> automatical parsing of different content types, such as JSON, as well as 
>>> allowing that to work for all request methods, rather than just POST. 
>>>
>>> 2. Modernising the API for the request object, adding attributes such as 
>>> `request.data`, and `request.query_params`, etc., rather than the uppercase 
>>> POST, GET, and so on.
>>>
>>> The first is a major stepping stone towards having (JSON or other) API 
>>> support in core — the "merge DRF into core" request that comes up 
>>> frequently. (The other main side of that would be a review of serialization 
>>> and forms, in light of developments such as Pydantic, attrs/cattrs, and 
>>> django-readers, but that is **not** on topic here.) This was first 
>>> suggested in 2011, but has made little progress in that time. [0][1]
>>>
>>> [0]: https://groups.google.com/g/django-developers/c/4c4xT3ULNLk
>>> [1]: https://code.djangoproject.com/ticket/21442
>>>
>>> The second Adam Johnson proposed 2020, and was nearly merged bar Mariusz
>>> **blinking** at the size of the distruption, particularly for 
>>> documentation
>>> throughout the community, for no change in behaviour. [2][3]
>>>
>>> There was an inconclusive discussion about whether we right there[4] 
>>> but, at the time I linked the modernisation to the content negotiation 
>>> issue, as the feature needed to pay for the change. 
>>>
>>> [2]: 
>>> https://groups.google.com/g/django-developers/c/Kx8BfU-z4_E/m/lFXTF0IMCQAJ
>>> [3]: https://code.djangoproject.com/ticket/32259
>>> [4]: 
>>> https://forum.djangoproject.com/t/technical-board-vote-on-ticket-32259-modernize-request-attribute-names/10255
>>>
>>> Digging further into the history, with a mind to move these issues 
>>> forward, having **not** merged Adam's patch first time gives us the needed 
>>> pathway forward, I hope.
>>>
>>> I think there have been two reasons the content negotiation suggestion 
>>> has not progressed:
>>>
>>> 1. It's been all or nothing. Numerous times it's been requested to 
>>> **just** add JSON handling, but that's been bounced back to the full 
>>> proposal, adding customisable parsers and so on, which has then 
>>> stalled.[5][6]
>>>
>>> [5]: https://code.djangoproject.com/ticket/27415
>>> [6]: https://code.djangoproject.com/ticket/32646
>>>
>>> 2. There's a backwards compatibility concern, particularly with 
>>> multipart request bodies, where currently you'd get a string, which you'd 
>>> then try to parse yourself, not expecting an already parsed dictionary, for 
>>> example.[7]
>>>
>>> [7]: 

Re: Advancing the "content negotiation" and "modernising request object" proposals.

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

This first-step solution is good with me. It will allow everyone to switch
to request.data (etc.). And there’d be a clear way to use your own logic to
set request.data if needed: write a middleware (or view decorator, view
class, etc.).

What should request.data be/do in the case of an unsupported content type?
Currently request.POST returns an empty QueryDict. But DRF raises
UnsupportedMediaType if it has no matching parser, which is translated into
a 415 Unsupported Media Type response.

DRF’s behaviour feels more correct to me, since it allows terser views that
don’t check the content type explicitly. But it’s less backwards
compatible. I’m not sure which I prefer.

On Thu, Nov 10, 2022 at 3:14 AM charettes  wrote:

> Hello Carlton,
>
> This is not an area of the code base I'm heavily involved with but the
> increment approach you are proposing over this lack of feature support for
> basic content negotiation seems like a sane approach to gradually make the
> landscape better in this area without trying to get everything just right
> in a single stab.
>
> Adding ``request.data`` with support limited to JSON bodies at first seems
> the minimal step to lay some foundations towards revisiting the inclusion
> of very core/HTTP centric features that are sadly only available in DRF at
> the moment.
>
> +1 from me.
>
> Cheers,
> Simon
>
> Le mercredi 9 novembre 2022 à 06:32:53 UTC-5, carlton...@gmail.com a
> écrit :
>
>> Hi all.
>>
>> I'm looking for a high-level sanity check if you would.
>>
>> I've been trying to see a way forward through a nest of issues around two
>> concrete proposals:
>>
>> 1. Adding "content negotiation" to the request object, allowing
>> automatical parsing of different content types, such as JSON, as well as
>> allowing that to work for all request methods, rather than just POST.
>>
>> 2. Modernising the API for the request object, adding attributes such as
>> `request.data`, and `request.query_params`, etc., rather than the uppercase
>> POST, GET, and so on.
>>
>> The first is a major stepping stone towards having (JSON or other) API
>> support in core — the "merge DRF into core" request that comes up
>> frequently. (The other main side of that would be a review of serialization
>> and forms, in light of developments such as Pydantic, attrs/cattrs, and
>> django-readers, but that is **not** on topic here.) This was first
>> suggested in 2011, but has made little progress in that time. [0][1]
>>
>> [0]: https://groups.google.com/g/django-developers/c/4c4xT3ULNLk
>> [1]: https://code.djangoproject.com/ticket/21442
>>
>> The second Adam Johnson proposed 2020, and was nearly merged bar Mariusz
>> **blinking** at the size of the distruption, particularly for
>> documentation
>> throughout the community, for no change in behaviour. [2][3]
>>
>> There was an inconclusive discussion about whether we right there[4] but,
>> at the time I linked the modernisation to the content negotiation issue, as
>> the feature needed to pay for the change.
>>
>> [2]:
>> https://groups.google.com/g/django-developers/c/Kx8BfU-z4_E/m/lFXTF0IMCQAJ
>> [3]: https://code.djangoproject.com/ticket/32259
>> [4]:
>> https://forum.djangoproject.com/t/technical-board-vote-on-ticket-32259-modernize-request-attribute-names/10255
>>
>> Digging further into the history, with a mind to move these issues
>> forward, having **not** merged Adam's patch first time gives us the needed
>> pathway forward, I hope.
>>
>> I think there have been two reasons the content negotiation suggestion
>> has not progressed:
>>
>> 1. It's been all or nothing. Numerous times it's been requested to
>> **just** add JSON handling, but that's been bounced back to the full
>> proposal, adding customisable parsers and so on, which has then
>> stalled.[5][6]
>>
>> [5]: https://code.djangoproject.com/ticket/27415
>> [6]: https://code.djangoproject.com/ticket/32646
>>
>> 2. There's a backwards compatibility concern, particularly with multipart
>> request bodies, where currently you'd get a string, which you'd then try to
>> parse yourself, not expecting an already parsed dictionary, for example.[7]
>>
>> [7]: https://code.djangoproject.com/ticket/28678
>>
>> The way around the backwards compatibility concern is to introduce a new
>> code
>> pathway at `request.data` that handles things in the new way, whilst
>> deprecating `request.POST`, which could either be removed or become an
>> alias to
>> `request.data` at the end of the deprecation period. (Given the behaviour
>> change, and django-upgrade ongoing development, I'd lean now toward
>> removal, I
>> think.)
>>
>> In order to get this done, I'd like to introduce this **without also
>> solving the pluggable parsers issue** in the first version.
>>
>> That is, I would like to add `request.data` to provide parsed data from
>> the request body, for all request methods, together with `application/json`
>> content type handling (and multipart parsing for `application/json` parts
>> as well) **but** I