
Django core no more - jsmeaton
https://www.b-list.org/weblog/2018/nov/20/core/
======
merlincorey
This is an in-depth discussion of Django's proposed governance changes from a
long-time committer (since 2007), release manager, and board member of the
Django Software Foundation.

It's also an interesting mini history of the governance of the project and
formation of things like the DSF.

Essentially they plan to dissolve the Django Core and make the development of
Django more open to new contributors.

------
frankwiles
This has been a long time coming and overdue to help “open” things up. Thank
you James for taking a leading role to help make it happen!

I and other DSF/Django members will likely be around here to answer any
questions anyone may have.

My biggest hope is that this isn’t seen as scary or concerning to anyone. It
should not be scary to any current users or contributors to Django.

~~~
charred_toast
If it means anything, reading the first part of it inspired me to want to
contribute to it, if at all ever possible, because I believe Django is
important enough to sustain and to recognize these issues before they evolve
into problems is good idea.

------
jamestimmins
Personally, I find this quite timely, because I recently wanted to get
involved in open source and looked into working with Django. Their ticket
tracking system looks far easier to follow and get involved with than many
other large projects, but still I find zero tickets marked 'easy pickings' and
'unassigned'.

This may be the wrong response, but my takeaway is that the project is too far
along for new contributors, so it's better to try and get involved with
smaller, less well known projects where I can contribute.

In part, I'm commenting because I would _love_ for this to not be true, and
would be quite excited if someone pointed out flaws in my understanding!

~~~
pjtr
If you like that ticket tracking system (Trac), maybe consider getting
involved with that itself as well:

[https://trac.edgewall.org/query?status=new&keywords=~bitesiz...](https://trac.edgewall.org/query?status=new&keywords=~bitesized&desc=1&order=id)

'bitesized' tickets are "small work items, ideal for new contributors to dive
into the code".

[https://trac.edgewall.org/wiki/HowToContribute](https://trac.edgewall.org/wiki/HowToContribute)

~~~
bionoid
Just out of random interest - does anyone know what happened to the Apache
Bloodhound project [0], which was based on Trac? I was somewhat optimistic
when it started.. let's be real, Trac has many serious shortcomings, but it's
still extremely practical for a small team of technical users.

No progress was made on GenericTrac [1] whatsoever for the 5+ years I ran Trac
in production and followed the project. Bloodhound made a single release, and
then I never heard a word about it again.

[0] [http://bloodhound.apache.org/](http://bloodhound.apache.org/)

[1]
[https://trac.edgewall.org/wiki/GenericTrac](https://trac.edgewall.org/wiki/GenericTrac)

~~~
pjtr
It seems not that many people have enough time and long-term interest in
contributing significant improvements to such projects.

GenericTrac was mainly a plan by Christian Boos, who worked a lot on Trac in
~2005 - 2013, but has not actively worked on it much after that.

Apache Bloodhound was mainly triggered by one company (WANdisco), which has
lost interest in it. Of the few remaining people, Ryan J Ollos has since
become a Trac core developer instead, and has been keeping very active there.

Recently Gary Martin (formerly(?) WANdisco) "restarted" Apache Bloodhound as a
Django app, not based on Trac anymore.[2]

> Trac has many serious shortcomings

I don't disagree, but would be interested in what you think they are.

[2]
[https://lists.apache.org/list.html?dev@bloodhound.apache.org...](https://lists.apache.org/list.html?dev@bloodhound.apache.org:2018-10)

~~~
bionoid
First let me say that I haven't looked at Trac since I ditched it from
production (prior to the Bloodhound incubator). So don't expect this to be
fair criticism today.

> It seems not that many people have enough time and long-term interest in
> contributing significant improvements to such projects.

I am not convinced that is the only reason. The trac mailing list was (in my
opinion) hostile to people that showed up with an idea and willingness to work
on it; nobody would give encouragement or guidance and there was usually a "f
__k off and fork " or two in there. People aren't going to stick around to
contribute if the maintainers/community are not interested to include them.
That is/was a serious shortcoming.

The data model was not well thought out, with lots of UNION and UNION ALL in
the queries, row-modelling things that should be normalized, and so on. That's
probably my #1 technical issue, in terms of the code, it was hard to correctly
add functionality because things were just read into RAM and manipulated there
(expert SQL knowledge is of no use when working with the trac database)

The switch of templating engine did not make the codebase simpler, but instead
made everything more convoluted and difficult to work with.

The primary issue though, was the lack of Milestone customization, and the
incredibly poor performance. I had to implement custom search, custom indexes,
custom reports, and custom everything else. And this was a 5-person team,
using only ticketing (no repo, no wiki, nothing).

~~~
pjtr
I would say the mailing list has become much less hostile and more supportive
then.

The data model has not changed much, so that criticism is still relevant.

The templating engine has been switched again (ClearSilver -> Genshi ->
Jinja). I don't know if you refer to the first or the second switch. I also
don't know if this was an improvement or just even more churn.

Lack of Milestone customization: I'm not sure I understand.

Poor performance: How many tickets do you have?

~~~
bionoid
> the mailing list has become much less hostile and more supportive then.

Glad to hear that! Running an open project is hard.

> [...] switched again (ClearSilver -> Genshi -> Jinja)

Genshi was current when I used it; I wasn't aware it had switched to jinja (or
it slipped my mind by now..)

> Lack of Milestone customization: I'm not sure I understand.

Back then, there were no custom fields for milestones, and the code didn't
make it easy to do. Of course, this means you need changes to search
facilities, and any other parts of the codebase. I had to write that __also,
__and the target workflow was not at all complex.

As for the performance, we had about 20k tickets and 2k milestones when the
system was replaced. By then it had been completely unusable for a long time.

Honestly, the only positives I have to say about Trac concern real-world usage
by a hacker. Once you've learned it, and hacked it to your liking, it's very
productive. But to get to that point, it's a sixty feet tall stack of ugly
hacks, and frankly I would not recommend it to anyone...

Again to be clear, I did not look at the trac repo in many years, nor do I
intend to.

~~~
pjtr
Ah, I thought my ~300 milestones was pushing it. :)

I see. Milestones still have no custom fields. Did you ever send your
customizations upstream?

~~~
bionoid
No, unfortunately it was nowhere near good enough for that, it was just
massacred to solve the problem.. Plus it was built on probably 20 patches from
trac-hacks in the first place.

Very hard to find the time to upstream something like that when you are on a
limited budget in the first place..

~~~
pjtr
So "It seems not that many people have enough time and long-term interest in
contributing significant improvements to such projects" wasn't that wrong. ;)

------
lsh
It's come a long way and this is yet another interesting feature Django is
incorporating. I hope it injects the fresh blood they're after.

Did anybody else feel inspired by a 'rapid web development' platform in 2005?
[https://tech.slashdot.org/story/05/08/02/0051258/django-
pyth...](https://tech.slashdot.org/story/05/08/02/0051258/django-pythons-
rapid-web-development-framework)

------
techie128
Big Django fan here. Love the project and framework. I love DRF and other
plugins. I am a developer but I haven't ever felt the need to contribute for
two reasons - 1) It works 2) The entry barrier is high. For instance, other
than some basic documentation, I haven't seen anything more substantial
"howto" to contributing including Django developer events. For instance,
Carlton Gibson had a DjangoCon 2018 talk about contributing to Django. This
was a good start. However, we need more meaningful engagements for example a
code walk through for different areas of the Django codebase. Maybe a howto
series on hacking on different parts of the codebase. This is more engaging &
useful for someone who wants to contribute. It is a step beyond saying "here's
a git repo, mailing list and issue tracker. Now, go forth and code!"

------
btown
I wonder if the continued use of Trac and a mailing list in a modern, Github-
centric world is holding back contributions, perhaps even more so than the
need to reshuffle responsibilities among existing contributors.

Consider that if a Django user wants to contribute _with an account they 're
already logged into_, the only thing they can see is
[https://github.com/django/django/pulls](https://github.com/django/django/pulls)
\- a wall of structure and external references, with no clear way to suggest
features. To the community's credit, people gently redirect "stray" pull
requests to the proper channels, but this still has to feel like a form of
rejection to well-meaning developers!

Compare this to
[https://github.com/facebook/react/issues](https://github.com/facebook/react/issues)
and
[https://github.com/rails/rails/issues](https://github.com/rails/rails/issues)
\- inviting colors, a clear way to raise issues one click away from the
codebase itself, centralized discussion of those issues, automatic links
between PRs and issues. Nobody is left behind; any suggestion can become a
discussion with decision-makers in place. This is what the modern developer
has come to expect.

I love Django as a framework - it's a set of abstractions that make a ton of
sense together, but simultaneously are much more explicit and easier to dive
into than Rails. I can command-click my way through the entire stack in VS
Code and know _exactly_ what's going on; when there's a customization to make,
there's almost always two or three hooks I can use to make it happen. And it
pains me that there seems to be a fear of change and a fragmentation of
contributor tooling that's holding it back from evolving. I don't know that
Trac -> Github is the best path, but I hope that this is the first of numerous
innovations that the core and board intend to discuss earnestly over the
coming years.

EDIT: As I consider what I've written above, I'm thinking about a concept of
TTFK - "Time To First Keystroke" that's intended as part of a contribution.
Once you start writing an issue or coding a PR, assuming there's a clear path
for it to get accepted, that first keypress is the start of an avalanche that
gets obsessed developers deeper and deeper engaged. But if you look at the
README on [https://github.com/django/django](https://github.com/django/django)
, count how many clicks it takes, and words to read, and new platforms to
join, until you can type your first character on a _non-documentation_ feature
request. It's not a fun number. Process/triage is great, but you have to have
a way that someone's unstructured contribution can gain structure over time
without requiring them to retype it or jump through hoops.

~~~
Rjevski
I agree with this. I can deal with Trac (although I’d still prefer GitHub) but
mailing lists are a big no-no for me.

The funny thing is that I read this post yesterday and thought about
contributing to Django... and they lost me when I saw “mailing list” somewhere
in there.

~~~
vkazanov
..and what's wrong with mailing lists? Too complicated? A need to have
discussion of the patch in question?

it's very easy to write an email and there are some benefits to it. I.e, you
don't need an account on a proprietary (Microsoft owned) system.

~~~
Rjevski
It’s just a bad user experience.

If Microsoft is an issue there are self-hosted options available like GitLab.

~~~
ubernostrum
If you know of something which is easy to set up, easy to administer, easy to
use and provides better handling of multi-way threaded discussion, I'd be
interested to hear about it.

(I know Python is experimenting with a forum-based solution, but I worry about
the burden of both yet _another_ account to create and site to check, and
finding people to maintain and moderate it)

------
crucialfelix
This is a good move. I found the process of contributing to be very off
putting and so I gave up.

~~~
jsmeaton
Can you elaborate any more? I'd be keen on hearing about what made it so off
putting and what could be done better to improve that situation.

------
speedplane
Django's stance of not supporting NoSQL and other alternative databases is
such an embarrassment. Not saying they need to chase every fancy new
technology, but for a "batteries included" library, they sadly miss a whole
bunch of features.

------
devxpy
Wow, Django must be used by many of the biggest companies around. Instagram
comes to mind...

Its so retarded to me that companies don't have a model for paying the open
source projects they built their whole infrastructure on :(

~~~
ubernostrum
Not a fan of your word choice there.

But it's worth noting Instagram has been a generous corporate sponsor of the
DSF, and hired a Django committer several years ago. I just don't know of any
company that currently has employees paid to work _on_ Django, in the same way
that, say, several big tech companies pay people to work on various parts of
the Linux ecosystem.

~~~
nikisweeting
Does Eventbrite pay Andrew Godwin to work on Django? He's certainly a prolific
contributor but I'm not sure if his Django work is officially sponsored by
them.

