Just as a FYI, there’s a main-business (as in “not side”) project that’s a Django-based “project management” system (glorified issue tracker). It’s now called “Tenzu”, recently released as open source, but it’s the new incarnation of the late Taiga. Now, last I played with Taiga was years ago, around it’s 1.0 release, and I never used it in anger, so I have no idea if it can fit our bill, but some people in this topic might be interested.
Discourse - Demo - Source
3 Likes
Curious about the Django community’s thoughts & experience with Codeberg (https://codeberg.org/), which has issue tracking (The Basics of Issue Tracking | Codeberg Documentation). I have been using the platform for the past year and have been very pleased with it.
// JRO
This is brought up every now and then and it’s a bit of a wish of mine to just move to GitHub issues. Any time I talk to a current or former fellow about this, I get a lot of pushback. They quite like it, they know how to use it, we’d need to migrate the issues, etc. As they’re the people using it the most, I’m inclined to trust it.
I also think that if Django was started today, we’d probably just use GitHub issues and evolve it. I don’t find this a very compelling argument though, I don’t think inertia is a bad reason to stay. As mentioned, the migration will be expensive in terms of volunteer time if nothing else.
But I do want this. The benefit, I believe, is that many newcomers are confused about even where the tracker is. Then, how to use it. The search is very cumbersome, I often just use a Google site search rather than trying to fiddle with the various search widgets. This is a better UX for me. Site search also works well for GitHub issues, and I find their text based advanced search to somehow be more intuitive than Trac’s GUI approach.
My understanding is that Trac also causes some (probably minor) problems around keeping the design consistent with the rest of the website. For example, if something in the site’s nav bar changes, this change needs to be repeated in Trac. Probably not a huge deal, and not worth migrating for, but there have been times when they’ve been out of sync so it’s at least a nice bonus. And it keeps the code and issues together, which I do like, instinctively.
It also simplifies the infrastructure that the ops team needs to keep running, and I understand there are often issues around Trac being down. Though I also realise the ops team are likely to be involved in the push to migrate, it’s at least, I assume, less work in the long term.
Python made it work, I think we can too, especially if - as Markus suggests - we ask them for some advice. What I question is if we can get enough buy-in, especially from the fellows.
Just a quick note, for transparency, that we chatted about this some more at DSF Office Hours this week[*]. The summary of the conversation is that: to move this forward, the next step would be to put together some sort of informational DEP (or other document, doesn’t have to be a DEP) that lays out and analyzes the various options and – critically – provides some sort of framework for decision-making. There are a lot of stakeholders here, so this is probably a situation where we have to first decide how to decide before doing anything.
A couple of folks expressed interest in working on this, and may have begun already – I’m not naming names so I don’t accidentally voluntell someone, but if anyone is working on this and wants to 
so folks know who to talk to if they want to help, that’d be nice.
[*]: Every Wednesday at 6PM UTC; contact me or any board member for joining info.
2 Likes
Thanks for quick note @jacobian. I’ll be working on a DEP for this. Some others have expressed interest in working with me on that. If you are interested in working with me and haven’t already reached out, please do so. Looking forward to putting something together
1 Like
Ryan, I’d also be happy to help work on this, so consider this my expression of interest.
1 Like