Does anyone have any good sources or suggestions on how I could look to try and begin to improve documentation within my team?

Documentation in software projecte, more often than not, is a huge waste of time and resources.

If you expect your docs to go too much into detail, they will quickly become obsolete and dissociated from the actual project. You will need to waste a lot of work keeping them in sync with the project, with little to no benefit at all.

If you expect your docs to stick with high-level descriptions and overviews, they quickly lose relevance and become useless after you onboard to a project.

If you expect your docs to document usecases, you're doing it wrong. That's the job of automated test suites.

The hard truth is that the only people who think they benefit from documentation are junior devs just starting out their career. Their need for docs is a proxy for the challenges they face reading the source code and understanding how the technology is being used and how things work and are expected to work. Once they go through onboarding, documentation quickly vanishes from their concerns.

Nowadays software is self-documenting with combination of three tools: the software projects themselves, version control systems, and ticketing systems. A PR shows you what code changes were involved in implementing a feature/fixing a bug, the commit logs touching some component tells you how that component can and does change, and ticketing shows you the motivation and the context for some changes. Automated test suites track the conditions the software must meet and which the development team feels must be ensured in order for the software to work. The higher you are in the testing pyramid, the closer you are to document usecases.

If you care about improving your team's ability to document their work, you focus on ticketing, commit etiquette, automated tests, and writing clean code.

That way we’ll just find maintainers went near extinct over time, just like COBOL developers that are as rare as they are expensive.

Care to take a shot at figuring out why COBOL is still used today?

I mean, feel free to waste your time arguing for rewrites in your flavor of the month. That's how many failed projects start, too, so you can have your shot at proving them wrong.

But in the meantime you can try to think about the problem, because "rewrite it in Rust" is only reasonable for the types who are completely oblivious to the realities of professional software development.

special treatment for free

They filed a bug report, with a reproducible bug.

Some guides on how to contribute to FLOSS projects even go as far as listing this as one of the main ways to contribute to projects.

But here you are, describing a run-of-the-mill bug report, filed among hundreds of bug reports, in a ticketing system explicitly opened to the public so that everyone and anyone in the world could file bug reports, as a request for "special treatment for free".

Do you think every single person filing a bug report is asking to be given special treatment for free? Everyone's bug is very important to them too. What makes you think this case is special or even any different?

This is really not about "corps".

You eager-to-be-outraged types are desperately trying to make a storm in a tea cup over a normal bug report filed among hundreds of bug reports.

Again, if you replaced the name of those filing the bug report with "random joe", would you still have faked all this outrage? Would you throw the same tantrum if it was even any other business?

They made a demand, based on a product launch time line.

If you read the same bug report I read, you wouldn't make that claim. They expressed their personal needs, which are their own and theirs alone, and don't extend beyond their personal roadmap.

This is absurdly rude (...)

The issue stated they found a bug that they had to get fixed. They said it was important to them for their own personal reasons. It's laughable to describe what amounts to a run-of-the-mill bug report as "absurdly rude".

Do you actually work on software for a living?

treating open source like slave labor

I'm sorry, what? Do you even pay attention to what you're writing?

TIL rust has some sort of ratings for libraries/dependency code.

A random guy going through the trouble of putting together a site to subjectively rate other people's work is hardly something that's language-specific.

I'd wager that adding a single tag/field to represent the programming language is all it takes to make the system universal.

Also, that's not even language-specific. It's package-centric.

I get it, joining bandwagons is fun. That's not a substitute for thinking things through, though.

By the way, npm even supports package auditing, warnings, and autopromoting packages and its dependencies. You don't hear people constantly parroting switching projects to Node.js over this, though.

You are making an extreme assumption, and it also sounds like you’ve misread what I wrote. The “attempts” I’m talking about are studies (formal and informal) to measure the root causes of bugs, not the C or C++ projects themselves.

I think you're talking past the point I've made.

The point I've made is that the bulk of these attempts don't even consider onboarding basic static analysis tools for projects. Do you agree?

If you read the post of other studies you've quoted, you'd be aware that some of them quite literally report results of onboarding a single static analysis tool to C or C++ projects. The very first study in your list is quite literally the results of onboarding projects to Hardware-assisted AddressSanitizer, after acknowledging that they haven't onboarded AddressSanitizer due to performance reasons. The second study in your list reports results of enabling LLVM’s bound sanitizer.

Yet, your personal claim over "the lack of memory safety" in languages like C or C++ is unexplainably based on failing to follow very basic and simple steps like onboarding any static analysis tool, which is trivial to do. Yet, your assertion doesn't cover that simple step. Why is that?

Again, I think this comparison is disingenuous. You take zero effort to address whole family of errors and then proceed to claim that whole family of errors are not addressed, even though nowadays there's a myriad of ways to tackle those. That doesn't sound like a honest comparison to me.

Non profit doesn’t mean they earn nothing

You need a valid business model to keep an organization ticking. Staff doesn't live out of hopes and dreams. It's hard enough to get a for-profit software company to stay up. If your starting point is that the company is not focused on getting a profit then it all sounds as hopes and dreams instead of an actual business plan.

I have two accounts,

The last post to !opensource@programming.dev was 6 days ago.

During the past week, the community received two posts. Only two.

In the past two weeks, it received 8 posts.

Again, if you care about content, all you need to do is post content. Please don't ruin everyone's experience by deploying spambots that add no value at all. Be smart about where to invest some effort.

Here are some possibly related communities in the instance:

Instead of deploying annoying bots, if you care about traffic then you should post some discussions from now and then.

@Ategon , !opensource@programming.dev is basically dead and you haven't posted a single message there. If you care about content, shouldn't your effort be focused on creating posts instead of deploying annoying bots?

I’m sorry, which of those recent commits aren’t things a single linter run would catch?

Ask yourself why the code still had those typos, and why nobody did anything about it except the guy contributing code cleanup commits.

I think that pattern matching and sum types are orthogonal to monads, and aren't really relevant when discussing monads as alternatives to exceptions. C++ didn't required any of those to add std::optional or std::variant, and those are already used as result monads.

Supporting Result and Either monads in the standard would be nice, but again this does not stop anyone from adopting one of the many libraries that already provide those.