> But a github-like setup, project package, issues, branches, PRs.
Well, how is that supposed to work and not run into essentially the same problem? You can use any version control system, but only after you have integrated it into the Debian meta version control system?!
> Where is the web ui?
Why would you want a web UI, especially if it's supposed to be user friendly? I have a very nice and powerful development environment ... why would I ever want to have a "Debian Web UI" for inspecting a package's source code instead of just using the tools that I know well how to use?
> I honestly feel like these commands are magic because I don't know what they clone from.
Well, there is documentation that explains what they do?! Like ... man apt-get? And it's not really all that complicated either.
> (and I have to be on debian)
Well, you can just download the source packages from the website if you want, but in the common case that you just want to inspect or modify the code of the package that you have installed, what's easier than have apt download and unpack it for you?
Also, of course, that's all only relevant to the Debian packaging, not the upstream source.
> slack or similar...
What do you mean by similar? Proprietary software with a monopolistic supplier that you cannot participate in unless you enter into a contract with that third-party supplier under their terms, and that forces you to use their user interface instead of integrating it with your existing communication infrastructure? How is that more user friendly than "start any free-software IRC client of your choosing if you haven't one running yet, and join the channel (or use some web IRC client if you want)"?!
> This assumes on a debian machine.
Well, it is meant for reporting bugs in a Debian install, so ... yeah?
Also, again, you don't need to use that, but it's the easy way in the common case that you are indeed on a Debian system when you want to report a Debian bug.
> How do you subscribe
You click the "subscribe" link in the line "Reply or subscribe to this bug." at the top.
> comment
You click the "Reply" link in the line "Reply or subscribe to this bug." at the top.
> propose a PR
Same as above, just put the URL of the repo to pull from in the email.
Though in practice just putting the patch into the email is the usual approach, given the nature of packaging bugs (the fix usually is relatively simple).
> where do you find the source.
You click on the "docker" (or whatever the package name is) link in the "Package: docker [...]" line at the top, that gets you to the bug tracker overview page of that package (essentially the list of all bugs related to that package), there you click on the "docker package page" link in the "You might like to refer to the docker package page, [...]" line at the top, which gets you to the list of available related packages and their versions, where you click on the relevant package and version, which gets you to the info page about exactly that package in exactly that version, which, among many other things, contains links to the source package in the right column.
That might seem like a lot of clicks to get from A to B, but if you realize that bugs are not specific to single package versions, but Debian as a distro of course is built on specific versions that are published as packages, it actually makes sense.
> I have used some of the debian tools like apt-get source, but it takes a long time to learn these things, and I forget them.
Well, yeah, it certainly is something you have to learn if you want to use it, just as github is something you have to learn if you want to use it!?
I just don't see how anything like github would be a replacement for Debian package management tools. I mean, the purpose of apt and dpkg and the like is not to be general-purpose software development tools, they exist just for the purpose of packaging and building software for Debian. If you want to package and build software for a distro, you'll naturally have to learn how to use the packaging tools of that distro, and if you are just interested in the upstream source of some software that just also happens to be packaged for Debian, then why bother with any of the Debian stuff?!
> A github-like system is much more intuitive.
Are you sure you don't just mean "I am more familiar with github"?
I find github just annoying in that it's constantly trying to get me to use their user interface instead of just giving me easy access to the raw data and letting me use my own tools (and I am not interested in using github for anything, I just am confronted with it when other people choose to host their software on it).
> many open source projects have old infrastructure,
I still don't see what's wrong with old infrastructure?!
> that's hard to use.
Well, hard to use infrastructure is bad, whether old or new, isn't it? Github, for example, is relatively new, and just terrible. I can't even report a bug in projects hosted there, I'd first have to create an account with them just to post a simple bug report, it's just such a terribly complicated workflow (not to forget I'd probably have to accept their TOS?).
I still don't really see any similar problems with how Debian operates from what you have written!?
> And I fully understand how that infrastructure came to be, and why migrating away is super hard.
Well, I still don't see why one possibly would want to migrate away in the first place!? I mean, not that there is nothing that could be improved, but I don't really see anything that "switching to" would somehow make things better.
> My point is: github-like development flow have dramatically better usability and, hence, lowered the bar for participation.
Did it? I guess it depends on what you mean by "github-like"? My experience with github specifically is completely the opposite.
I have contributed to quite a few projects, with usually very low barriers to get involved. Usually, you just send an email with the patch (or a pull request for more complex changes) to the mailing list or maintainer, and that's it (or maybe a few more mails back and forth to discuss some improvements or whatever, but no up-front cost before you can get started, no need to create accounts, no need to learn additional user interfaces, ...).
On the other hand, I had a few bug fixes for projects that were hosted solely on github where I couldn't find any way to submit them without first making an account with github and learning their proprietary user interface, so I just ended up dropping them on the floor.
How is the latter an improvement?! Or is it?
> I wish more of the big open source projects would embrace the importance of these advancements in usability.
But ... what are those advancements in usability? Really, I still don't see any. I mean, not that usability couldn't be improved here and there, but what you write so far mostly reads to me like "if you know github and don't know non-github, then github is easier to you than non-github" ... which might be true, but would generally be equally true for anything else, and in particular doesn't really have anything to do with usability!?