If you have those problems it's probably time to invest into clearing all those risks and uncertainties up. Even if you just let it sit because it works, there is no telling what it means for company, IT, and data security.
It's not like everything has to be upgraded at once either. Windows is quite compatible. The main thing is the hardware requirement when upgrading to 11.
A standard for build output might make sense to me. Maybe just throw cache stuff in .cache and build output to .build (with intermediate artifacts in there as well potentially).
When enabled via flag, dotnet puts stuff into artifacts/obj, artifacts/bin, and artifacts/publish respectively. I like that. So much better than every proj folder having their own.
And there's really no need to make it a dot folder. For the publish you don't want to anyway. And you may want to navigate to bin as well, to run a build or inspect the output.
The git compatibility is necessary for adoption and connected use.
jj does significantly reduce the work interface, but the git compatibility increases complexity again.
I tried it out a little bit a few days ago, and found it interesting. But given my git knowledge and tooling, I can't reasonably switch. First, I would miss my TortoiseGit Log view (entrypoint to everything). But also, the connection between jj and git seems complex and potentially error prone.
As a fresh and independent tool I can definitely see how it's much easier and better, especially for people not familiar with Git.
It's a fair statement and personal experience, but a question is, does this change with tool changes and user experience? Which makes studies like OP important.
Your >95% garbage claim may very well be an isolated issue due to tech or lib or llm usage patters or whatnot. And it may change over time, with different models or tooling.
Documentation: A place where we can create documentation for projects that don’t have the documentation or is very basic.
Why create or extend documentation outside of the project when you could improve the project docs themselves?
Projects that are open source but don't allow easy doc contributions?
I find contributing to projects very easy. When I read some docs, and find an issue, I create a pull request with a fix. When I'm interested in a project, I take a look at open issues. Often the website and software project are separate repos with separate issues.
I find the idea of a community of people sharing ideas, open tasks, seeking and finding contributors compelling, but I'm skeptical any new platform could reach critical mass. Maybe that'd be a matter of approach and long term effort.
If you license your games for the duration of them being active, then it makes sense.
The biggest issue, miscommunication, and often illegal practice is calling it buying when it is only a limited subscription. IIRC Steam recently (finally had to) change the wording away from "buying". Because it's not buying if you don't own the product afterwards.
What's with the signed 2.0 vs unsigned 2.1 Windows installer?
Winget apparently already references the unsigned installer. Does it take them a while to sign? I would expect winget to reference only signed installers if they provide them.
I'm surprised they don't have a major release announcement. The GitHub Release is a change log, and the Release page, without a dedicated subpage for the release, reads more like "individual improvements from last release".
What are "frontend language"s?
Just wondering if this is very incomplete or due to scoping.