Jake Howard

Great question! There are a few changes which need making in `django-tasks` before I'd want to call it "production-ready", and that's even before it's "Django ready". But after those, there's...

CI is still failing. However, on reflection, I'm not sure the added complexity is worthwhile. Because task functions must be explicitly allowed, there's no ability to gain remote-code execution inside...

It's deprecated, but `condition` isn't supported in 4.2. I'm open to adding a Django version check, and passing either `condition` or `check` as needed, so long as it's not much...

@Alwinator it's a draft PR with failing tests and conflicts. It's not as simple as just "merging" it I'm afraid. Once it's ready, it'll absolutely be merged.

`readthedocs` feels like as good of a platform as any - lets us keep different versions live. `CONTRIBUTING.md` is probably also needed, but I think is separate to documentation.

Much of the documentation already exists on https://github.com/django/django/pull/18627. Sphinx is fairly heavy. Given most of the documentation will be duplicated from Django, we'll want something very simple. `mkdocs` is also...

Probably not much. The intention is for `django-tasks` to be 100% API compatible (at least a subset of) with the Django API. So most of the documentation may be covered...

Yes. If you're interested in working on it, by all means do. I don't assign issues to people specifically though - anyone can work on anything.

I think it'll need something a little more complex than this, as both the worker and migrations need to use this value. It might be that a [database router](https://docs.djangoproject.com/en/5.0/topics/db/multi-db/#automatic-database-routing) is...

I think a better way to handle this would be using a database router. I don't think one should be included, but at least documenting how to write one would...