Re: #21978 include production-ready web server

Hi Pete, this does look interesting. And I agree that this is something that would be nice to have in core in one form or another. That said I think we have to do it iteratively (ie in smaller parts) and evaluate along the way. Since you asked for feedback, I'll tell you what I'd do differently

Re: Creating internal/admin pages without Models

Hi Carlton, While django-admin-views indeed gives us the option to add custom views, it still is locked to the App/Model based organisation which reflects the DB. Moreover, it still necessitates that I build the page by hand. I'm interested to kn

Re: #21978 include production-ready web server

IMHO, adding YAML support would introduce a dependency that's not needed: why not just use Python, instead of ini/yaml/toml? Projects could have a (.gitignore) env.py that settings.py imports and then sets the appropriate variables from it. You can use straight assignment, e.g. LANGUAGE_C

Proposal: Clarify individual members page

Along the lines of discussions about redefining requirements for board seats (e.g. https://groups.google.com/g/django-developers/c/FbNaAq3rz6c), I think it would be helpful to clarify what we want from individual members of the DSF here: https://www.djangoproject.com/foundation/individual-membe

Re: Changing the role of the Technical Board

I'm going to avoid trying to get too much into point-by-point back-and-forth argument here, and try to present the larger picture. The Technical Board has multiple active responsibilities under DEP 10. Let's look at some of them: 1. Canvas for feature proposals once per feature release of Django.

Re: Changing the role of the Technical Board

I agree the Technical Board has not followed the letter of DEP 10, and I think the things you have highlighted are all valid failings, but I want to focus on - what should we do to remedy them? Given the lack of candidates we already have, if we ditch the current Board and try to elect a new on

Proposal for Django Core Sprints

Hi everyone, Following Andrew Godwin's example, I too share with you a proposal that I made during DjangoCon US 2022 and that I have already shared with some of you. Inspired by an article by Will Vincent, I wrote my proposal for Django Core Sprints, and its genesis, in an article and would also

Re: Changing the role of the Technical Board

On Wed, Oct 26, 2022 at 12:02 PM Andrew Godwin wrote: > At this point, it is my view that it is our job to govern with the people > we have, and the time and energy they can provide, and that's my intention > with these suggested changes. > If the problem in front of us is that the Technical Boa

Re: Changing the role of the Technical Board

My intention is indeed for us to run a new Technical Board election come the end of 4.2, with much better and more explicit communication about what will be expected of the new members, and a larger candidate pool to pull from to hopefully make that work. I will be posting my actual proposed DE

Re: Proposal for Django Core Sprints

Organizing sprints is a fine idea, but: * They should be designed around the assumption of remote-first, not "hybrid" or in-person-first, and there should be no language in the description whatsoever about in-person participation being important. There simply are too many factors involved in tryin

Draft Steering Council DEP

Hi all, As a followup to my previous post about potential changes to the Technical Board - for which I thank you all for the feedback - I have taken the process to the next step and written a draft DEP: https://github.com/django/deps/pull/75/files (If you wish to see the DEP with styling, it c

Re: Proposal for Django Core Sprints

Hi Paolo, I do like the overall idea - a few thoughts below. My first concern for this, which somewhat echoes James, is that trying to organise an additional in-person event that a large number of contributors are expected to go to is difficult. Funding considerations are one concern - we woul

Re: Proposal for Django Core Sprints

Hi James, First of all, thank you for your feedback. On Thu, Oct 27, 2022 at 1:10 AM James Bennett wrote: > * They should be designed around the assumption of remote-first, not "hybrid" > or in-person-first, ... My proposal is that of hybrid sprints for the reasons I have listed in my article,

Re: Proposal for Django Core Sprints

Hi Andrew, Thanks also to you for your very detailed answer. On Thu, Oct 27, 2022 at 1:54 AM Andrew Godwin wrote: > ... trying to organise an additional in-person event that a large number of > contributors are expected to go to is difficult I am aware that this proposal of mine to the DS

Re: #21978 include production-ready web server

Hi Jure, My point was mostly about hieracrhy, not the exact format. That said on a technical level it is true that the same can achieved via python -- after all this is what settings.py is currently. But the hard truth is that many people prefer a established configuration file format (for some

Re: Proposal for Django Core Sprints

Hybrid sound the best way, with remote first as otherwise you are excluding people who would need air travel that's not covered by someone else and can be very expensive how and are thus increasing a carbon footprint for something that really doesn't need it On Thursday, 27 October 2022 at 01:4

Adjusting DEP 10 "How Django is released" section.

Hi all, Almost scared to say it but, the discussion on the TB renaming and election eligibility changes highlights the inappropriateness of the How Django is released section of DEP 10. It currently reads: How Django is released No later