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.
1 Like
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.
3 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.
2 Likes
In the event there is a proposal to migrate off Trac, I’m really hoping it goes through a regular DEP with Steering Council approval. What I’m hearing from several voices (and I’ll add mine) is that even if we came to the conclusion that another tracker was better to some degree, there’s discomfort with innovating in this area. For me, that’s exactly where the “steering” in Steering Council comes in: to encourage or discourage innovation in a certain area of Django, even if enough volunteers have graciously offered their time and talent to implement changes (volunteers Django is very fortunate to have!)
That said, if this fizzles out before reaching such a stage because there isn’t enough consensus, I do agree that having some sort of document reflecting the “architectural decision” that was made would be helpful for the future.
3 Likes
Great points made here. There is actually an informational DEP that is being worked on right now to hopefully have this all documented for future reference (at the very least!).
There is another thread asking for feedback on specific needs and wants of a tracker so that this information can be collated into that Informational DEP.
I totally agree with this sentiment:
For me, that’s exactly where the “steering” in Steering Council comes in: to encourage or discourage innovation in a certain area of Django
3 Likes
I’m a bit lost about what should be discussed here or on Trac migration informational DEP - Feedback required, so forgive me if I bleed context from one to another.
+1, but we may need to define “scripting.” My understanding is that Trac needs this sort of custom tooling because it lacks automation/integration solutions. Github, for example, already has almost unlimited capability for integrations, and issues can be edited or comments can be added using integrations. We wouldn’t need a custom “scripting” solution if we use what GitHub provides.
+1. I’m curious how they handled their filtering/sorting/search needs. Also, what other projects can we check for similar use cases?
https://trac.edgewall.org/ticket/13774
Trac project is still discussing dropping the Python 3.5 support and it looks like 3.6 support will stay there for years to come. The roadmap doesn’t look bright. Trac’s Python support policy is already pulling the updates on https://code.djangoproject.com/ and I don’t think it worths it.
It would be wise to move away from Trac before it needs to be maintained by DSF. I found myself in a similar place with a couple of different projects, the most notable being graphene-django, and I should say it’s a black hole for all types of resources.
- Issues and pull requests live on two different systems, confusing the newcomers.
- It’s not clear what Trac actually provides with the current setup. Is the wiki alive? Do we want to keep it alive? If so, how is it different from the docs, and when should one prefer one over the other? Is the dashboard it’s in the ideal state, or does it require a significant amount of volunteer power to get in shape? (An example of the best version of the dashboard in my mind is https://clickpy.clickhouse.com/ but for Django issues)
- Trac is old and ugly. I know this is not an objective comment, but I believe it’s the common take. I don’t remember the last time I worked with Trac in any other project, it may be more than 10 years ago. For a new contributor who is trying to understand the SDLC of Django, an old system that nobody even remembers is not the most friendly welcome. Having SVN instead of git would give the parallel feelings. It doesn’t look “modern”, and if anything, it makes you feel like something will go wrong and you won’t be able to get help.
- How do you feel about continuing with Trac?
I think it’s a no-go. Even if Trac was the perfect tool and everyone liked it, with its current state of maintenance, it’s a ticking bomb.
- Should we begin exploring alternatives? If yes, what other options should we consider beyond GitHub Issues and YouTrack?
- I guess GitHub is the obvious first choice. I’m concerned about the label/filtering capabilities, but do we need to limit ourselves to what GitHub provides? Can we extend the dashboard and add filtering and management screens? By syncing Github issues and a Django installation, even Django admin could handle this, and it might be much cheaper to develop.
- Using Django admin for Django development could significantly increase the development speed of admin Eating your own dog food - Wikipedia
- +1 for YouTrack, but I’m not sure about its licensing approach, and it doesn’t have the “everything is in same place” factor.
- Jira? It provides everything mentioned in this post and even more, but I’m not sure about a couple of points:
- Is it fast enough? Can it handle the data size Django have?
- Is it cheap enough?
- Is its maintenance easy & cheap enough?
- I guess we are not looking for commercial and cloud-hosted solutions unless there is a very special reason not to ignore them. This rules out tools like linear.app .
- Redmine? Not sure how it compares to Trac in terms of being modern and well-maintained, but I’m surprised to see it wasn’t mentioned yet.
- If now isn’t the right time for a change, what criteria should we establish to determine when it is time to evaluate alternatives?
If we postpone this any further, it won’t get any easier, so I think the earliest time with enough resources is the right time.
I saw many people sharing concerns about preserving history, and I think everyone understands how vital it is, so I believe keeping history intact won’t be an overlooked task. I’m more concerned about keeping the old (Trac) links working and how to redirect them to the new system.
5 Likes
I think that migrating off Trac is wise, though with downsides that we’re likely to have a hard time tracking down. I appreciate the work going into understanding our current system better, its benefits, and what will make it difficult. Especially with the precedent of Python moving to GitHub, I have a strong suspicion that will be the wisest place for us to end up as well, but especially the metadata challenges on GitHub have been pretty annoying to me, so it’s not without some reservation.
I appreciate the call-outs to make sure we’ve thought about preserving history and keeping old links working if possible. That’s something that we should definitely keep on whatever checklist comes out of this work. I’m not sure exactly where such a checklist should go, perhaps on whatever draft DEP we come up with to work through the issues.
1 Like
I am interested in helping with this. I’m particularly interested in learning about the Python transition to GitHub and what they learned along the way. I’d appreciate any links to relevant threads or documentation of the process.
I saw many people sharing concerns about preserving history, and I think everyone understands how vital it is, so I believe keeping history intact won’t be an overlooked task
I wanted to throw in one little point: Please respect the privacy of the contributors and be mindful what is migrated to the new issue tracker. People did consent that their PII is stored at Trac, but the same people may not consent to having their PII migrated to eg., GitHub. Comments may include PII, too, dramatically complicating that problem. Whatever the solution, it should align well with the GDPR.
Doom writes:
I wanted to throw in one little point: Please respect the privacy of the contributors and be mindful what is migrated to the new issue tracker.
Good point and by no means a little one.
Comments may include PII, too, dramatically complicating that problem.
Not a lawyer, but I think moving a comment to another platform could be seen as quoting the original comment on trac and that could be ok.
Another thing that just popped up in my head was, when you mentioned the GDPR, what about the right for people to leave trac and get their accounts deleted? I can’t see any easy accessible option for that in trac? But in that case only the accounts will get deleted and any ticket or comment created by that account will not be deleted? So getting back on to the topic: I could imagine an announcement to move trac to github will create a higher demand to leave trac before the move. And what if they want their content to be deleted as well?
I don’t believe that this is a loop hole to bypass the GDPR.
This certainly is a possibility and deleting one’s personal data is a right protected by the GDPR.
As an open-source project, the Django Project could and should be a lighthouse for GDPR-compliance and show that it takes responsibility when it comes to the member’s personal data and privacy. I believe legal counsel is important and the Django Software Foundation should support this migration with some of it funds to get a legal report to guide the migration plans.
Ok, but personal data/information != public content you created on the platform. And the latter is not subject to GDPR. I guess you still have the copyright to your content, but ownership could also have been transferred to the DSF or the legal entity that runs the platform. But there is no use for further speculations and I also would see the necessity to get some legal counsel.
1 Like