> instead of helping projects
This isn't how it works. You don't help projects by pretending the football-stadium-sized issues with them don't exist and using them despite their flaws.
Trac is an awful, awful piece of software. It's awful to set up, to use, to maintain, to gather feedback from, it's awful for just about everything. If in some very weird parallel universe it gathered even 1% of the following that Github has today, you'd find a 20 page google document at the top of HN about its issues.
This is me being nice. Kallithea is a lot better, but it's just a far poorer Github-like clone. You might as well use Gitlab.
The other advantage of Github is the network effect. You don't have to create yet-another account, which removes a barrier to contributions.
When you're an open source project, you can think of the "Submit issue" button as your payment form. Same UX rules apply: The user must be able to file the issue as easily as possible. You should not throw obstacles in their way. You should not ask 50 questions when they can't answer half of them, especially if they just want to tell you "You have a typo in decode.c" or even just say hi.
Time to enrollment. How easy is it to become a contributor? When I file an issue on your project, I am doing you a favour - you should help me help you. I have myself given up on several large scale projects because they use shit software for bug tracking. It's not fun.
A lot of people don't understand this today. Github has fixed these issues and this is a huge reason why they are popular. And before you say anything, this document here is about is not time to enrollment, but quality of life when you are already a developer (especially on large projects). I'd certainly love for GH to fix those.