I agree, having issues/support questions fragmented, can be a huge big deal breaker. Just imagine you’re running into an issue so you:

search via. web search engines, check out the project’s issue tracker, look for recent tweets mentioning the project, skimm through comment sections of the blog, link aggregators, reddit, mailinglist archives, IRC logs, …

So it’s in reality not only a comment section only issue, but a problem of information spreading across multiple sources. And how could you mitigate this? Create a “Support Statement”. Link to this support statement in all of your communication channels, kindly point out the statement if ignored and start moderating in worst case.

Projects often provide some outdated information on their blogs. Including a comment section can encourage others to contribute with more up to date details. This then can help people on a lost track to figure out where to continue searching, reducing their effort and used time for each problem. Other side, if I run into an issue, thing something can done be differently or want to add something helpful - I comment and hope, someone will find my informations usable.

In general, comment sections often provide helpful additional details. The scope of a single blogposting is always limited. Comments are a way of expanding such scope and this without having many trade offs.

Side note: Gitlab is also having a comment section below their release notes and before upgrading I, more than once, found some helpful informations in there.

I think as long as you stay with this ‘specific traditional way’ of providing informations, a comment section can be a good thing and should not just be shut down. It’s hard to come up with a different solutions that other people will actually use. I’d really like to see different approaches, but I don’t think you’ll suddenly figure out different ones, just by reducing the quality of status quo.

Maybe it would be cool to have an auto-generated list of issues, summarizing all issues introduced with each release. Thank’s for reading.

Edit: Rephrasing Gitlb sentence a bit (still not perfect).

If they were doing that “just cuz,” I’d agree with you, but the fact they have a thorough list of what they need to self-host, plus my own experiences working on Kiln, make me give them the benefit of the doubt.

When I was working on Kiln, I was constantly pushing for self-hosting, way before the product was “ready,” for the exact reason you’re pointing out: we should put our money where our mouth was. And I won that fight pretty early, when we were right around the level of features Gitea 1.0 or 1.1, albeit with a less-polished UI. My theory was that going to the product even before we hit our minimal internal viable product (MIVP?) would help us shape those features, and that at any rate using Kiln couldn’t be worse than using bare Mercurial hosting.

Oh boy was I wrong. What actually happened was that we implemented the shittiest possible version of the missing features almost immediately so that we could get work done. I’m talking hybrid Perl/Smalltalk services running on my personal desktop busy-polling the Kiln prototype installation to generate RSS and email notifications based on hand-written rules I modified when people asked me to. I’m talking having to take time out from getting to feature completion to write a Mercurial history import rebuilder that we never would’ve had to build if we’d waited for our schema to stabilize. I’m talking shoving out a clunky ASP.NET adapter that buffered the whole Mercurial request in RAM before even starting to process the thing because it at least worked and I didn’t have time to fully wrap my head around writing a proper ISAPI plugin.

The result was we got distracted from actually making Kiln work and probably lost a month doing one-off POS versions of features we knew we’d need to build properly anyway, plus damaged a bunch of internal goodwill at Fog Creek on the quality of Kiln, plus hurt our own morale by associating our own product with being incomplete and annoying. I am not proud of that decision and would not repeat it.

We can argue a bit over some of the things Gitea throws in their MIVP bucket (becoming an OAuth provider would definitely be nice, but you could always just make an extra account and give your CI explicit login permissions), but a few key ones, like line comments on pull requests or improving the notification system, have really, really strong echoes of the situation I saw on Kiln. They’re targeting getting to self-hosting, and they know why they don’t want to go there yet. I support them waiting.

That said, I’m happily using Gitea myself and have been really pleased with its stability, UI, and upgrade story. Doing viable backups is also really easy, and abandoning it for another Git hosting option would be really, really easy, because Git. So don’t use it if you need the same features the Gitea team does, but if it’s just a light install on a non-review-heavy workload, I’d at least give it a look.

Infrastructure is money and pain; I don’t blame them at all for using a platform that’s ready to go. Plus it seems weird to complain that they should put more of their time and money into the project?

Fair comment. I can only think that Gitea doesn’t yet provide some of the core functionality they need (maybe pull requests or an issue tracker?). That said, a quick glance at their website didn’t actually tell me what functionality they do provide.

Still, I do like the idea of a lighter weight self-hosted alternative to GitLab.