Too many top-level files+dirs

[JanCVanB]

I think we, once again, have too many top-level files & directories. Here are screenshots of how zoomed-out my browser and terminal need to be to see them all (without column breaks, in the terminal's case):

[JanCVanB]

I think this is both unwelcoming for newcomers and unwieldy for contributors. Does anyone else agree?

[JanCVanB]

How many directories is too many? Files? Should hidden vs. unhidden affect our self-imposed limits?

[brian-carroll]

I don't agree with this, I think it's OK.

For newcomers there are several beginner-oriented markdown files among those top level files. And there are only a few directories that have clear meanings. The rest is all config files for tools, which, in my experience, every project has.

I don't think most users of a language actually browse the compiler repo. How often have you done that in your usual language? Remember the stage we're at. Working in the compiler repo as a language user is a temporary situation.

As a contributor I don't find it unwieldy. I actually think it's pretty compact! I think I've learned to just skim over things like dot files and .md files.

I think most languages or other big projects like web frameworks look like this. And most big software projects I've done at work look like this too. I randomly picked a few compilers and frameworks and they all look about the same to me. https://github.com/rust-lang/rust https://github.com/python/cpython https://github.com/rails/rails

I guess different people have different experiences. What kind of projects are you comparing to?

[Anton-4]

I don't think it matters a lot for longtime contributors but it probably does for newcomers, it's hard to deny that showing lots of new information is overwhelming. If we can reduce the list without disadvantages we definitely should.

My suggestions:

• Create a folder CONTRIBUTING with:
  • AUTHORS
  • BUILDING_FROM_SOURCE.md
  • CODE_OF_CONDUCT.md
  • CONTRIBUTING.md
• put FAQ.md, TUTORIAL.md and roc-for-elm-programmers.md in the getting_started folder

Earthfile and .earthignore can be deleted in the near future.

[folkertdev]

nesting such things makes them less discoverable. I think that is actually a bad thing. The repository should only be relevant for those wanting to contribute to roc (at least long term, that may be slightly different now) and we should optimize for that target audience, making the information that they would look for, easy to find (i.e. not nested).

Consider other languages

• rust
• julia
• python
• ruby
• haskell
• zig

all of these go "below the fold" with the list of files

[Anton-4]

Nesting can make things harder to find, but it can also guide people. It's a tricky balance :)

[JanCVanB]

Hooray for nuanced and contextual perspectives 😃 I'm now convinced that language/compiler repos necessitate above-average top-level breadth. Once the roc-lang org has more repos that are designed for newcomers & simplicity, that will also alleviate my "unwelcoming" concern.