That seems like a tradeoff between people discovering a project and people developing that project. People initially discovering a project usually want the README; people developing a project may potentially want either.

I never look at the Code page of projects I work on. I'm always going straight to the pull requests or issues.

I always thought the Code page's intended audience was new people checking out the repo for documentation or to peruse the code (usually after checking out the README).

I find that the code helps me get oriented, like running ls in a project's directory after cd-ing to it.

That is true, I don't really know what the answer is. You could do something like show half code/half readme, with extra code hidden behind a fold.. but I'm sure that would annoy devs working on those additional hidden files.

I'd be happy with a README-first design that had a link to move the README below the code, and that remembered which one you want on top for each repository. (Along with a preference for logged-in users to decide what they want.)

You can also put a Readme in any folder and it will show up the same way. You usually wouldn't want those up top while browsing the files though. So it's also about consistency.

I agree this sucks. If it helps someone else avoid scrolling, I discovered that the "readme" text on the right side (right under the "about" block) is a link to the top of the readme at the bottom.

I'm gonna say it: we need to not dunk on designs by being inconvenienced for like, a second, while we figure out something new. People are way too quick to say something sucks.

Agreed!

Related: I was updating a bunch of dependencies yesterday, and so was going through looking at what's new in a handful where I was behind a major version or more. "Releases" is even harder to find now (it's in the sidebar). I've never understood why it's relegated to a being a sub-item of "code" when it seems to me it should be on the same as information hierarchy level as "issues" "wiki" etc.

I'd really like to see Releases on the top nav bar, and possibly even Readme should be the first item, Code second.

I’d love to learn more about this! Why would a top level of Releases be useful?

I think partly it's just the inconsistency that bothers me, but when I'm being a consumer of a project it's one of the main things I look at -- certainly more than many of the other top-level items.

* "Actions" are basically only useful to me as an active project contributor.

* "Security" is a pretty niche tab -- I think personally I've clicked on it only a handful of times, ever

* "Insights" I had forgotten about to be honest (and obviously don't use it), but even as I look at it now, I think it's somewhat useful for judging how active a project. For mature projects (that don't need active development) it says almost nothing. I personally do a fuzzy judgement on Releases, popularity, # Issues open/closed, # merged PRs, # and age of open PRs, # contributors.

I use "Releases" as a consumer in mainly three ways:

1) To help judge the quality and maturity of a project, in terms of how easy it will be to deal with as a dependency. Are releases being used (vs published adhoc)? Are there betas? Is there a changelog or curated release notes? Is semantic versioning being used? How frequent are releases?

2) When updating dependencies, and looking for breaking changes or things I need to update in usage.

3) For downloading, when it's the only way -- though this is typically linked from the main README, and I'd generally only care about the latest.

It's where a lot of projects keep their binaries, appended to releases. They've made it harder to get to.

Highly dependent on how I got to the repo.

If I know what repo I want and am going directly to it, sure. If I'm looking at lots of repos that match a search (either on GH or somewhere else), say... looking for a library that does a thing and there are many choices, the first thing I'm going to look at probably isn't the readme. More important in those cases for filtering out the chaff are date of last commit and the issues board, looking for signs of life rather than signs of abandonment.