Neither. A button should show action it performs.

Read official docs, then rewrite some small own project in it.

It's not a responsibly of the format, so, at most, it's a mere side effect. In any practical process which could result with truncated data, even if it handles data with such property, it should be wrapped in a container which includes length. At the very least, it would allow to trace the source of truncation, e.g. was the data originally truncated, or was it truncated in the process, and change the format without shooting in oneselves foot. And the generating side should always provide success flag which should be properly handled, since it may produce syntactically correct, but semantically invalid data. Such as checking exit code of process which generates json/yaml in question

You just check the exit code, no? The other process may fail while generating syntactically correct data too, regardless of format.

That's not a problem of a format and should be handled by transport or storage.

Agreed, and I have more arguments against commit signing.

• Commit immutability is undesirable, and mutable commits are not compatible with signing. For instance, pull requests are squashed and rebased to keep linear history, and changes are cherry picked around. It does not change authorship, however it changes hashes and invalidates any signatures. Or, say, one wants to adopt an otherwise FOSS project which though contains some copyrighted material in its repository, which needs to be filter-branched away, again invalidating the signatures.
• In our world where stuff randomly gets criminalized I prefer to avoid being undeniably linked to my code.

BTW this topic has common considerations with now mandatory (on GH and more places) 2FA. For the latter reason, and also for own convenience and for reducing risk of losing access to your account (which I assess as much higher than risk of leaking my password to third parties) I make second factor public, effectively reverting to 1FA.

Why would you need to flesh it out it the first place? If you have serious projects I take it you're not total beginner, so don't waste time on projects with no purpose.

Being open to new opportunities and being dissatisfied with you job are different things. I've mainly meant that these statistics are biased. Hypothesis is that people not interested in doing their work hang out on SO instead, as a result a lot of people hanging out on SO are "considering a career move".

IMO it just says which and why people hang out on SO.

Hard to understand as in learning it or as in reading others code?

These technologies, although archaic, clumsy and insecure, are not a fatal problem - these are still open and widely accessible anyway.

However, this case may indicate that the projects author is an autocratic hermit type, locked in a bubble with his ancient tech and not really welcoming outside contributors and bug reports, so these IRC and maillists come with worse things such as CVS, C89 code, build system handwritten in shell which only works on author's machine, and complete unwillingness to discuss, fix, modernize and make the software more portable, so not only contribution attempt would be a waste of time, but simply using such project could pose risks.

Of course that's not necessarily the case and it may be just good old IRC and maillists, and that should not be the problem for most people. For me personally though, for I contribute to hundreds of F/OSS projects, this is a show stopper, as I absolutely want to minimize routine tasks. One-two git/gh commands is what I'm used to, while installing extra software, going through registrations, copypasting patches, monitoring additional sites for feedback does not work. In the best case I would fire-and-forget, so if someone on some god forgotten self-hosted gitlab asks to fix a thing in my PR I will never see it. Or more likely, I would put such contributions into my contribution queue with lowest priority, and since the queue of what I want to improve is always growing and never shrinking, it effectively cancels them.

And I could add that you don't really need realtime communication channels to contribute - technical stuff may and should be discussed in async mode as in issue/PR comments (or email reply thread in the worst case), where unrelated discussions don't happen in parallel, message size is not limited, history is preserved, nobody is in rush to reply, you don't need to actively wait for reply and cannot miss it because you've disconnected, someone forgot to tag you or it was just list in the chat.

Summarizing, the project should be on [the most popular VCS hosting at the moment], which is currently GitHub, any other choice makes it much less accessible and welcoming. For chat use whatever you want, for it's not related to contributions. If you think otherwise, at least stick to open protocols.