5 ms·
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
by btown 8y ago
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.
- ubernostrum 8y agoI'm extremely skeptical of any "just use platform/service/tool X" type of suggestion, largely because I've been doing this long enough to know that "just" needs to be in scare quotes and that often the claimed benefits don't materialize. Django does need a place to store the tickets, and GitHub's tracker... is not great. I'd honestly want to look at adding OAuth or other easier signup/account management to Trac before I'd look at moving to GitHub issues.
- btown 8y agoA fair and valid point, and to Django's credit, they actually do have Github OAuth as the signin procedure for Trac! Unfortunately, it's still a new interface for people to learn and be afraid of - and most importantly, it's a place where activity can be hidden from people who are just browsing the codebase, so the project looks less active than it actually is! Bots that mirror content/comments between the various platforms might be an interesting interim step that could minimize those scare quotes, and achieve many of the benefits in a minimally invasive way.
- jsmeaton 8y agoEvery year or so someone brings up the prospect of moving from Trac to something else (mostly github recently). October was the last time this was brought up[0]. I'm of the opinion that Trac is probably blocking a number of people from contributing, even if that contribution is participating in comments and voting on issues. But that's exactly the kind of thing the community as a whole can be empowered to do without the old guard of core vetoing the suggestion outright. The python community are considering doing just that now with PEP 581. [0]https://groups.google.com/forum/#!topic/django-developers/aiyE__qSHBY https://groups.google.com/forum/#!topic/django-developers/ai... [1]https://www.python.org/dev/peps/pep-0581/ https://www.python.org/dev/peps/pep-0581/
- Rjevski 8y agoI 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.