@CyReVolt @jwildeboer @mxmehl Yea but.. software is also not only for people who know and use git. Documentation isn't really document-ey if your actual users can't access it because they don't know git.
Also, as a software developer, I detest email passionately and would rather switch careers than have to use email to organise anything.
@patrick @jwildeboer @mxmehl @CyReVolt But how do they contribute to docs, translations, etcetera? That's why Wikis are such a nice feature of Gitlab, and such a shame to lose.
We should always be pushing to make software development more inclusive to non-devs, it's the only way we end up making more things relevant to non devs. Crucial for accessibility, too.
@cathal @patrick @jwildeboer @CyReVolt I'm not sure whether you implied that, but #Gitea has wikis as well. They offer basically everything an average developer needs. So it's like Mastodon in comparison to Twitter, except that the users on different instances cannot easily connect and contribute comments or PRs.
#Federation would be a huge boost for Gitea (and other software supporting such a standard) and break the network effect that benefits Github and Gitlab.
@cathal @patrick @jwildeboer @mxmehl We actually dropped the Wiki and switched to sphinx for the docs in coreboot. I'd like to oppose the idea that "git is only for devs"; many documentation contributions come to projects from non-devs via git. That's actually what many projects even recommend for first-time contributers. :)
Also, nothing keeps you from hosting a wiki independently. It's another way of decentralization, decoupling infra.
I'd also be interested to have a web tool to simplify the editing process of a git backed documentation base (translations don't matter for coreboot, we don't have UI), but doing it that way ensures that it's part of the review process we have in place.
First of all, the complexity of the tool defines the threshold new users have to take to contribute. Git is quite complex for inexperienced users, they have to read a lot of documentation first. We had to make the experience in the FSFE that you can lose valuable contributors by that.
On the other hand, #Gitea but also Github offer editing files/creating PRs via the web interface only. Branch names ("patch-1") are not really helpful then, but it works
@mxmehl @patrick @CyReVolt @jwildeboer More informative patch names could probably be fixed with a PR to add a "describe your edit" box, like Wikipedia does.
I agree by the way, I know far more people who will never contribute of it requires a terminal, than I know people who will. And making things elitist by saying "you must be this techie to contribute".. well, you do you. But I think it's a regression in culture-not progress.
What I'm not open to however is to silo away documentation into a place where devs only get to see it by chance. That's what happened with the wiki we used to have, and that's what happens with a wiki in Github/Gitlab/Gitea - even if it were to be stored in a separate git namespace.
In my experience documentation really needs to live in the source tree (and undergo the same review processes as source code) to have a chance to remain synchronized and current. The other route would be to have writer communities that are strong enough to take care of that manually and on their own, but that's a weak spot in most open source projects.
tl;dr: hide git, for all I care, but keep documentation and source close together or they'll drift apart.
@CyReVolt @mxmehl @patrick @jwildeboer He fact that even professional devs have to keep checking stack overflow to figure out how to fix git borks suggests things are not so straightforward even when the terminal is elided.
It's not FUD to say "professional tools built for software development are designed with professional software developers in mind".
@CyReVolt @patrick @jwildeboer I agree to @cathal. At the FSFE, we manage our website with Git and ask voluntary translators to contribute their work through it. Although we invested a lot of time in documentation, it's a burden for many to contribute.
Git is an awesome tool, and I wouldn't want to miss it, but if you're not used to Git it can drive you crazy. The whole idea and concept is genius, but very unintuitive for many people. If you made diverging experiences, feel blessed :)
@bityz See my followup toot. For now, they have stopped the rollout of these trackers. The whole program is on hold while they reflect on the criticisms.
@MatejLach bring on @forgefed (or #sourcehut or #SaT or #GitSSB)! There are lots of projects working on a federated #CodeForge network, but there is a lot still to be done to get it all usable for anyone other than command line wizards. A good test project would be a docs forge, like #flossmanuals, but federated. If mere mortals can collaborate on docs using federated editing tools, they're ready for anyone to use.