If you put a lot of care and effort into the appearance of your README and its banner, you might find it a little frustrating that when people visit, the first thing they see is a wall of dot-files and .yaml and .mylinterconfig.yaml.rc.json, and so on. By the time they scroll down to your H1, their hands are so tired that they can't even think straight.
We've all been there.
But what if I told you... there's a clever trick you can do which is really unprofessional and inaccessible and confusing to any potential users or contributors, but it gets rid of all that clutter.
This repo demonstrates that technique.
See, GitHub has a funny quirk where there are three (or four) canonical paths where you can place your community health files - CONTRIBUTING.md, CODE_OF_CONDUCT.md, etc.
(i) At the root
(ii) Under docs/
(iii) Under .github/
(iv) For a user-global version, you can also use your personal .github repository
You can even do this with your README. If you put your README at docs/README.md, it will (probably) show up on your repo's "front page". If you have another version of the README at the root, however, that one will take precedence. However, if you put even another version at .github/README.md, that will in fact trump them all in the GitHub UI.
If you have any GitHub Actions workflows in your repo, then you can't get rid of .github/ - you're stuck with it. But you can hide everything else underneath it. The README will still show up when users visit your repo; the README will still have those little tabs for your Code of Conduct, and Contributing, and Security docs. And everything else is tucked away chaotically in a single folder and you can finally be happy. And everyone can marvel at your amazing banner. And they will probably never want to contribute to a project like this. Which is great because who wants contributors, really?
To be fair, it's an almost perfect plan - however, there is one operational difference - your LICENSE file will not be auto-discovered by the GitHub API. Or, rather, it will not be presented in the same first-class way. Now, from a legal point of view, that's not that relevant - but, it is one of the few asymmetries I've noticed.
To see the proof of this pattern, you can visit the what-a-mess branch to see the "normal" way of structuring a codebase. It's just a little demo app that prints "Hello World", but it's stuffed with a bunch of extra files for clutter. There's even a workflow that runs the app, and you can see that it works both on main and on what-a-mess.
The aim of this repo is (mostly) just to show you something quirky that you can do with GitHub. In case I haven't made it clear, this is an extremely bad way to structure an open-source project, and you should not do this with any serious project. As mentioned above, it's confusing, alienating, inaccessible, difficult for potential contributors to orient themselves, probably difficult to maintain, and it's very likely that your banner isn't that spectacular anyway.
So don't do this. On the other hand, it's a good trick to know - and I must confess I do utilize it to a certain extent - as a way to reduce clutter and move any documents or assets that are not that important and don't need to be living in your repository root. And, actually, to be really honest, I use it somewhat excessively in some of my projects where the default branch README is not meant to be a piece of documentation, but is rather an artifact or a part of the product surface area. So, I would say it does have a very limited use value. Because you should care about the appearance of your repo. But that generally doesn't justify going to lengths such as these.
MIT Copyright (c) 2026 Really Him