@dellagustin-sap interesting discussion!

A question out of curiosity:
Any hunch where the names of these files comes from? i.e. is this something that GitHub made up themselves, or does this have a longer history in open source? e.g. maybe there is even a RFC that suggests the use of certain file names.

Also, to clarify the improvement opportunity here:
If SUPPORT.md is indeed the better known file name for the kind of content that we now show under COMMUNICATION.md in our pattern, then it would make sense to rename this in our pattern as well, to reduce possible confusion of readers. Right?

Any hunch where the names of these files comes from? i.e. is this something that GitHub made up themselves, or does this have a longer history in open source? e.g. maybe there is even a RFC that suggests the use of certain file names.

I first learned of them by using GitHub. I have searched a bit about it, but could not find traces of the origin of the practice.

While searching for it, I also saw that https://opensource.guide/best-practices/ recommends documenting the vision for the project on a VISION(.md) file, which I quite like.
I have done this in a the README.md section of my main open source project (https://github.com/podStation/podStation) long with a History section, which, if larger, could go into a HISTORY.md.

It is kind of always the same idea with all of these files:

You can document it all in the README. If that grows too large, you can split it up.

Whether that split happens or not depends in parts on the personal preference of the maintainers.

It would be good to also "standardize" the README sections, to facilitate "linting" the repositories with rules that check for adoption of this pattern.

I don't believe support.md was on our radar when this was made. I am definitely open to changing it to standardize the document.