> By ancient convention, this is the first file intrepid explorers will read after unpacking the source. > 2. A pointer to the project website (if it has one)

> By ancient convention, this is the first file intrepid explorers will read after unpacking the source. > 2. A pointer to the project website (if it has one) And there you see a major shift that has happened in the last fifteen or so years. README files used to be for once you had obtained the code. But then GitHub co-opted them to be the home page, and other forges have by and large followed suit. I get why (repository info blocks on SourceForge and similar weren’t great), but I wish that brand of pragmatism hadn’t happened. Fortunately, I think that if you create another readme file in a .github/ subdirectory, GitHub should use that rather than the top-level readme file, so if you want to leave a proper readme file at the top level but direct casual viewers to an actual separate website with a deliberately stub GitHub readme file (“Go to <https://example.com https://example.com> for information about the product, or look at the [in-repository README.md file](../README.md) for information about the code.”), you should be able to do so. Otherwise you’re stuck either stuffing far too much inappropriate stuff into the readme file, or having people miss out on what they should see. If I were in this situation, I’d probably do that. (See also https://news.ycombinator.com/item?id=32211789 https://news.ycombinator.com/item?id=32211789 where I made this observation 11 days ago when a link to a code repository that contained a traditional README, instead of to a project page, led to surprise.)