Here's my take on each of these, leaving out async as that'd be more
dependent on where we were:
Secrets Manager
Many environments Django is deployed in use a separate secrets manager to
store and provide secrets per environment - either as environment
variables, files, or via a direct HTTP API. The project would be to design
and add an abstraction interface over secrets managers that allows users to
easily map to an external secret in a settings file. There's also room for
giving Django a better, built-in per-environments settings option too,
pulling from popular third-party patterns.
Django Service Hooks
Django has a lot tied to the HTTP lifecycle, and if you run it outside of
this, you miss out on some key things - like database connections being
closed properly, or logging, or some middleware. The project would be to
design and implement a separate way of calling Django from a service
framework - even if that framework was itself HTTP based (basically, don't
rely on Django having to run through WSGI/ASGI). Initial idea is to provide
a context manager that replaces the wrapping of a request, but the project
would have to include requirements-gathering and interviewing people who
use Django to power microservices to work out what they want.
Evented Datastores
Evented, or event-sourcing, database schemas are growing in popularity -
essentially, a way to implement an append-only pattern on top of a
relational database, where every single event that has happened is stored,
but you can still efficiently retrieve the current state of an item. Given
the way the pattern works, this would be possible to implement on top of
Django models - likely as a whole new Model subclass - and implement with a
matching QuerySet/Model API. It would require someone very skilled in
database design, and it's also arguable if it should be in Django itself,
or comprise of developing a third-party app alongside adding hooks/fixes to
the Django ORM where needed to make it work well.
GraphQL
Basically, work on an "official" graphql-to-ORM mapper for Django, probably
re-using a considerable amount of third-party work. This one could really
vary in its application, based on how much other "API-ish" work the project
includes (given that Django REST Framework is still separate, we should
follow that rough pattern).
Plus, some bonus ones that aren't Django code itself:
Django Case Studies
Our long-talked-about website which brings together case studies and white
papers about why people choose Django, aimed at companies working out what
they want to choose. This is likely only some coding and a lot of
writing/legwork, so may not be a good fit for GSOC, but should be on any
future plan we have.
Django Benchmarking
Django has had a benchmarking suite for a while, but we've generally got
more slack at tracking the effects each commit and release has. We should
institute a set of top-level benchmarks aimed at various areas (the current
set in djangobench are weak in, say, the HTTP-serving-speed area) and then
run them against pull requests and each release, so we can make sure Django
doesn't get slower while nobody is looking.
I'm sure there's a lot more, but these are top of mind at the moment!
Andrew
On Tue, Dec 10, 2019 at 11:52 AM Carlton Gibson <carlton.gib...@gmail.com>
wrote:
> Hey Andrew.
>
> Yes, Async, of course. It's not until *next July* so I'd still think we
> should list this. Worst case is there's exactly zero progress between now
> and decision day, in which case you could say that we could only accept a
> clearly capable candidate. (Jannis was once our GSoC person, so... :)
>
> The other ideas seem good: the secrets manager abstraction is a nice one
> (!)
>
> No rush, but when you have a moment, perhaps you could draft a couple of
> paragraphs for each? (Even if they don't go to GSoC directly, it would come
> in handy for the TB's direction guidance...)
>
> Kind Regards,
>
> Carlton
>
>
> On Tuesday, 10 December 2019 19:14:51 UTC+1, Andrew Godwin wrote:
>>
>> I agree that 2FA could be a good choice - some of the async support work
>> would also have been good, had I made more progress in the latter half of
>> this year.
>>
>> A couple of other ideas for big projects:
>>
>> * A secrets manager abstraction and built-in support for Vault, KMS, and
>> other common ones
>> * A proper story and hooks for running Django as a service (i.e. outside
>> of a traditional HTTP request/response cycle)
>>
>> And some ludicrous projects I'd still consider:
>>
>> * Evented/event-sourcing database work on top of the ORM
>> * A GraphQL-to-ORM mapper
>>
>> Andrew
>>
>>
>> On Tue, Dec 10, 2019 at 8:25 AM Carlton Gibson <carlto...@gmail.com>
>> wrote:
>>
>>> Hi all.
>>>
>>> It's time to start thinking about Google Summer of Code (GSoC). If we're
>>> going to participate and projects we might propose.
>>>
>>> This year was interesting. Sage in particular did well putting together
>>> a cross-db JSONField, but he was probably under-mentored,
>>> since Mariusz has spent quite a bit of time reworking the PR, and still
>>> has a bit to go, before we can pull it in, hopefully for 3.1
>>>
>>> So, one consideration we need to think about seriously is our capacity
>>> for mentoring. (This isn't just about the candidate's ability — Sage was
>>> able to implement all suggestions — we just didn't have as much capacity as
>>> we might have liked to think about the requirement implementation — and
>>> there were four of us actively giving some time each... — Anyhow, to think
>>> about.)
>>>
>>> Then it's projects. There are three that I have on my list that would
>>> require a "competent candidate":
>>>
>>> 1. Work on the migrations. Markus mentioned a particular ticket here
>>> but...
>>> 2. Make the parallel test runner work on Windows. ("fork" vs "spawn")
>>>
>>> And 3, and this is the big one:
>>>
>>> 3. Add 2FA to Django.
>>>
>>> This has been raised a few times:
>>>
>>> *
>>> https://groups.google.com/d/topic/django-developers/T-kBSvry6z0/discussion
>>> *
>>> https://groups.google.com/d/topic/django-developers/d92P2V0YrbI/discussion
>>>
>>> * ... others...
>>>
>>> If I'm honest, in 2020, it's the one "battery" I feel a little bit
>>> embarrassed we haven't got a story for. Maybe it's not possible in a GSoC
>>> type scope but...
>>> — What would it look like? What can we leverage? Is it worth a go?
>>>
>>> I'm looking at James, Florian, Joe, ... — who else has been keen here?
>>> I'm also looking at the Technical Board, which I'm thinking has (will
>>> have) a new guiding role to come up with suggestions for the direction of
>>> Django.
>>>
>>>
>>> Other Projects: Are there other ideas? (Do you have one?) Are there
>>> easier things that we could take "weaker" candidates for? But with that is
>>> there a commitment for the mentoring help they'd need?
>>>
>>> Anyhow, we have until January, so I'm just starting the discussion here.
>>>
>>> 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-d...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/af075d59-ece3-4044-9204-b690c746b9e0%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/af075d59-ece3-4044-9204-b690c746b9e0%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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/e1818353-9fa0-4e49-a6e9-4757f06c7e19%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/e1818353-9fa0-4e49-a6e9-4757f06c7e19%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAFwN1uqaniLZayw19gKOzEi3KT2EqD8VD-3%3Dd77FExQaYEUVYw%40mail.gmail.com.
