Update some WIP website pages

www/wip_new_website/content/bdfn.md

@@ -10,4 +10,4 @@ Something that needs figuring out between now and then is how to keep the langua
 
 (This would be easy to solve if zero happened to be the optimal number of new features to add over time, but unfortunately the programming landscape will change around the language, so remaining static is unlikely to be best. As such, the goal becomes finding a system which keeps the number of new features low without artificially forcing it to zero.)
 
-I don't have any plans for when the transition away from BDFN will happen, other than that I certainly imagine it being well after a 1.0 release of the language.
+I don't have any plans for when the transition away from BDFN will happen, other than that I expect it to be well after a 1.0 release of the language!

www/wip_new_website/content/community.md

@@ -3,30 +3,36 @@
 [Roc Zulip Chat](https://roc.zulipchat.com/) is the most active community gathering place.
 We love it when new people stop by and introduce themselves in [`#introductions`](https://roc.zulipchat.com/#narrow/stream/387892-introductions) so others can welcome you to the community!
 
-The Roc Online Meetup meets about once per month. The organizer posts a [when2meet](https://when2meet.com) for the next month's meetup, so we can find the best time that works for everyone
-who's interested in attending. This happens in [`#gatherings` on Zulip](https://roc.zulipchat.com/#narrow/stream/303057-gatherings). The organizer will then make a post on Zulip with a finalized time and a link to where people can join. They usually last between 1-2 hours, and consist of some informal presentations followed by casual conversation. They're fun!
+The Roc Online Meetup meets about once per month. The organizer posts a [when2meet](https://when2meet.com) for the next month's meetup in [`#gatherings` on Zulip](https://roc.zulipchat.com/#narrow/stream/303057-gatherings), so we can find the best time that works for everyone
+who's interested in attending. The organizer then posts a finalized time and a link to where people can join. They usually last between 1-2 hours, and consist of some casual show-and-tell presentations followed by conversation. They’re fun!
 
 We have not had a Roc conference yet, although there have been a few Roc talks given at conferences,
 and a few times when Roc community members have met up in person.
 
-## Code of Conduct
+### [Code of Conduct](#code-of-conduct) {#code-of-conduct}
 
 The Roc project enforces [a code of conduct](https://github.com/roc-lang/roc/blob/main/CODE_OF_CONDUCT.md). Please read and follow it!
 
-## Contributing
+### [Contributing](#contributing) {#contributing}
 
 All the source code to the Roc project is on GitHub in the [roc-lang](https://github.com/roc-lang) organization. The compiler and CLI are at [roc-lang/roc](https://github.com/roc-lang/roc), and there's a tag for [Good First Issues](https://github.com/roc-lang/roc/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22).
 
 The project has [many contributors](https://github.com/roc-lang/roc/graphs/contributors), and we like to invest in helping new contributors get started. If you'd like to become a new contributor (even if you don't know what you'd like that contribution to be yet), just make a post in [the "new contributors" topic](https://roc.zulipchat.com/#narrow/stream/316715-contributing/topic/new.20contributors) and say hello!
 
-## Design ideas, feature requests, proposals, etc.
+### [Ideas, proposals, and feature requests](#ideas) {#ideas}
 
-Roc doesn't have a formal process for managing design proposals. At the current size of the project, having a formal process (e.g. a [RFC](https://en.wikipedia.org/wiki/Change_request) system) would be more heavyweight than it's worth. Fow now, the guiding principle is that as a community we should all be friendly, supportive, and openly share and discuss ideas without the expectation that they will necessarily be accepted or not. We follow a [BDFN](/bdfn) leadership model today, although this is planned to change someday.
+Roc doesn't have a formal process for managing design proposals.
+
+At the current size of the project, having a formal process (like a [RFC](https://en.wikipedia.org/wiki/Change_request) system) would be more heavyweight than it's worth. Fow now, the guiding principle is that as a community we should all be friendly, supportive, and openly share and discuss ideas without the expectation that they will necessarily be accepted or not. We follow a [BDFN](/bdfn) leadership model today, although this is planned to change someday.
 
 There are three loose stages that a design proposal can go through in Roc: idea, proposal, and implementation. These are guidelines, not strict requirements; their goal is to prevent the outcome where someone does a lot of implementation work only to have their contribution never make it into the code base because it's determined that we wanted to go in a different design direction. Confirming ahead of time that the design direction is desired can prevent implementing something that ends up not being used.
 
-In the idea stage, people are encouraged to describe their idea and explore the problem, potential solutions, and trade-offs. It's a good idea to share the idea in [`#ideas` on Zulip](https://roc.zulipchat.com/#narrow/stream/304641-ideas). There's no prerequisite for sharing an idea (it's only an idea, after all!) and likewise there's also no obligation for any contributor to necessarily act on it.
+In the idea stage, people are encouraged to describe their idea and explore the problem, potential solutions, and tradeoffs. It's a good idea to share the idea in [`#ideas` on Zulip](https://roc.zulipchat.com/#narrow/stream/304641-ideas). There's no prerequisite for sharing an idea (it's only an idea, after all!) and likewise there's also no obligation for any contributor to necessarily act on it.
+
+If the idea seems promising and worth developing further (as confirmed by a Roc contributor with expertise in the relevant area—not necessarily the [BDFN](/wip/bdfn)), usually the next step is to get more specific with a written proposal that details all the necessary information about what the change would involve.
 
-If the idea seems promising and worth developing further (as confirmed by a Roc contributor with expertise in the relevant area, doesn't have to be the [BDFN](/bdfn)), usually the next step is to get more specific with a written proposal that details all the necessary information about what the change would involve. A written proposal isn't always necessary (e.g. it may be deemed a simple and uncontroversial enough change that we're comfortable proceeding straight to implementation), but since writing proposals can be time-consuming, it's definitely a good idea to get confirmation at the idea stage from an experienced contributor before taking the time to write one up.
+A written proposal isn't always necessary (for example, it may be deemed a simple and uncontroversial enough change that we're comfortable proceeding straight to implementation), but since writing proposals can be time-consuming, it's definitely a good idea to get confirmation at the idea stage from an experienced contributor before taking the time to write one up.
 
 There's no guarantee that a proposal will be accepted, and even if it is, there's no guarantee that something won't come up during implementation that changes the tradeoffs and means it doesn't end up making it into the language after all. But if it is accepted (again, doesn't have to be by the [BDFN](/bdfn) - although the BDFN does have final say if there's a disagreement at some point), that means a [Pull Request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) should be reviewed, and the general understanding is that the PR will be accepted unless some problem is discovered during implementation that wasn't anticipated at the proposal stage.
+
+This is the process we’re using for now, but of course it may change in the future!

www/wip_new_website/content/install.md

@@ -1,13 +1,16 @@
 # Install Roc
 
-Roc is a work in progress. It doesn't have a numbered release yet, but it does have nightly builds that you can download.
+Roc is a very young language with many incomplete features and known bugs. It doesn't even have a numbered release yet, but it does have [nightly builds](https://github.com/roc-lang/roc/releases) that you can download if you’d like to try it out without [building from source](https://github.com/roc-lang/roc/blob/main/BUILDING_FROM_SOURCE.md)!
 
-There are currently a few OS-specific issues:
-* macOS: There are no known compatibility issues, but the compiler doesn't run as fast as it does on Linux or Windows, because we don't (yet) do our own linking like we do on those targets. (Linking works similarly on Linux and Windows, but the way macOS does it is both different and significantly more complicated.)
-* Windows: There are some known Windows-specific compiler bugs, and probably some other unknown ones because more people have tried out Roc on Mac and Linux than on Windows.
-* Linux: The nightlies are built with glibc, so they aren't usable on distros that don't use (dynamically linked) glibc, like Alpine or NixOS. In the future we plan to build Linux releases with [musl libc](https://wiki.musl-libc.org/) to address this, but this requires [building LLVM from source with musl](https://wiki.musl-libc.org/building-llvm.html).
-* Other operating systems: Roc has not been built on any other operating systems. Building from source on them might work, but hasn't been tried.
+There are currently a few known OS-specific issues:
+* **macOS:** There are no known compatibility issues, but the compiler doesn't run as fast as it does on Linux or Windows, because we don't (yet) do our own linking like we do on those targets. (Linking works similarly on Linux and Windows, but the way macOS does it is both different and significantly more complicated.)
+* **Windows:** There are some known Windows-specific compiler bugs, and probably some other unknown ones because more people have tried out Roc on Mac and Linux than on Windows.
+* **Linux:** The nightlies are built with glibc, so they aren't usable on distros that don't use (dynamically linked) glibc, like Alpine or NixOS. In the future we plan to build Linux releases with [musl libc](https://wiki.musl-libc.org/) to address this, but this requires [building LLVM from source with musl](https://wiki.musl-libc.org/building-llvm.html).
+* **Other operating systems:** Roc has not been built on any other operating systems. [Building from source](https://github.com/roc-lang/roc/blob/main/BUILDING_FROM_SOURCE.md) on another OS might work, but you might very well be the first person ever to try it!
 
+### [Getting Started](#getting-started) {#getting-started}
+
+Here are some Getting Started guides for different operating systems:
 <!-- TODO detect current OS with browser and only show link for that, provide other button for others  -->
 
 - [Linux x86-64](https://github.com/roc-lang/roc/blob/main/getting_started/linux_x86_64.md)
@@ -16,65 +19,14 @@ There are currently a few OS-specific issues:
 - [Windows](https://github.com/roc-lang/roc/blob/main/getting_started/windows.md)
 - [Other Systems](https://github.com/roc-lang/roc/blob/main/getting_started/other.md)
 
-## Nightly
-
-<!-- link to nightly for currently detected OS(browser) and provide "other" button to reveal all -->
-
-## Roc CLI
-
-<!-- brief description on how to use the cli -->
-- Script `roc myApp.roc`
-- Develop `roc dev`
-- Test `roc test`
-- Run `roc run`
-- Build `roc build`
-- Format `roc format`
-- Documentation `roc docs`
-
-## Package Management
-
-You can include packages using an URL:
-
-```roc
-app "hello"
-    packages {
-        # basic-cli platform
-        pf: "https://github.com/roc-lang/basic-cli/releases/download/0.5.0/Cufzl36_SnJ4QbOoEmiJ5dIpUxBvdB3NEySvuH82Wio.tar.br",
-        # json package
-        # TODO update to json 0.3.0
-        json: "https://github.com/lukewilliamboswell/roc-json/releases/download/0.2.0/gh4zvR8xyEsef0R961Fcv5vxFEZJ-GJF-7bQwgL2Xz8.tar.br",
-    }
-    imports [
-        pf.Stdout,
-        json.Core,
-    ]
-    provides [main] to pf
-```
-
-A full Roc package manager will be developed in the future.
-
-<!--
-
-explain package manager design is still a work in progress
-the plan is to create a centralised index
-- ergonomicly integration
-- a fact that every language will have one
-
-in the meantime you can use package URLs
+### [Editor Extensions](#editor-extensions) {#editor-extensions}
 
-TODO Add an explanation for the URLs with the SHA and the tar.br. This explanation should only be revealed on click.
--->
+There is currently a [VS Code extension](https://marketplace.visualstudio.com/items?itemName=IvanDemchenko.roc-lang-unofficial) for Roc which includes instructions in its README for how to enable a Roc language server.
 
-## Editor Support
+Currently that language server has to be built from source; it would be a fantastic contribution if anyone could get it incorporated it into the extension directly. If you'd like to help with this, just make a post in [the "new contributors" topic on Zulip](https://roc.zulipchat.com/#narrow/stream/316715-contributing/topic/new.20contributors) and say hello!
 
-<!--
-explain that the high level design is a work in progress
-- Design goals for editor - we want Roc to ship with an awesome editor
-- Beginners learning to get up an running with an editor
-- Want it to run really fast etc
+### [Tutorial](#tutorial) {#tutorial}
 
-- Also link to VScode plugin
--->
+Once you've installed <code>roc</code>, check out the [tutorial](/tutorial) to learn how to Roc!
 
-- Language Server
-- Neo(Vim)
+<a class="btn-small" href="/tutorial">Start Tutorial</a>