consideration around .fsharp folder to make all fsharp tooling more cohesive

[smoothdeveloper]

I'd like the compiler and tooling to rely on the presence of such folder in the tree (walking up from place things are invoked, as it works with many tools), and potentially having a system wide and user specific one.

This would be a place where tooling such as:

• fsi
• fantomas
• fsharplint
• paket
• fable
• femto
• fake
• etc.

would use (end encourage usage) as their default, to not contribute to the root folder pollution, and also offer a single place where all projects can contribute documentation, under the fsharp.org or even official documentation.

Right now, each tool is kind of having their own approach, more or less well principled.

I'd like to gather feedback from the community, and have the deciders managing the fsharp compiler to express if this is to be under .dotnet/fsharp or .fsharp or whatever else makes the most sense, in order to not go against the grain of things being later decided in context of dotnet itself.

In context of fslang-suggestions, and for first actionable item, I'm interested in the concern of dotnet/fsharp#8880 (have FSI load extensions very conveniently, the issue needs overhaul and it probably starts with decision of having .fsharp, conceptually).

I'm also interested in the community deciding guidance that tools would adopt.

[smoothdeveloper]

@Tarmil brought [https://github.com/dot-config/dot-config.github.io](.config initiative) to my attention.