Comment by scrollaway
10 years ago
> 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.
Ubuntu has actively moved away from directing users to Launchpad to report a bug from a crash, and instead moved towards reporting to a crash database where they're triaged by actual developers.
Debian, in a similar vein, doesn't even have a web form to report bugs. As a result, almost every bug I've gotten on a Debian package has been clueful. At the very least, I know what version of the software they're running.
I've managed repositories that have gotten hundreds of low-quality issues. The poor filtering and curation functionality of GitHub ensures that a good deal of my spare time I have to work on those projects is spent managing the inbound issue flow, which is at least 90% noise.
Thank you for your time spent on Debian!
Gitlab is FOSS and does everything Github does (arguably) better.
The only reason one would use Github is for network effect.
Personaly i believe the ethical trade off to be too great, and I believe FOSS supporters should agree with me.
Look at diagoproject.com's ticket triage. They moved repository to github.com but cannot move issues there. It's built on trac and works. I am sure github.com will take ages to do such thing. Indeed even Python needs to rely on roundup for issues tracking. Now the developers will be more miserable since issues won't directly link to commits or changes which is loss of integrity.
Also from a ethical point of view it's wrong to trust for profit commercial closed source for community driven open source work. I am sure history will repeat and github.com will become future sourceforge.net.
The django project is one of the last big trac users. That doesn't mean it's a good idea to use trac. They should definitely move issues to github, or at least to a better issue tracking platform.
"I am sure github.com will take ages to do such thing" I have no idea what you're on about. I handled the migration of a massive bugzilla database to Github. Wrote this[1] in the process. The github team was super friendly and helpful in assisting me in the process with zero delays (shout out to Ivan!).
[1] https://github.com/jleclanche/bugzilla-to-github/