Merge pull request #5926 from roc-lang/wip-website-updates

Updates to WIP website

crates/reporting/src/error/type.rs

@@ -748,7 +748,7 @@ fn to_expr_report<'b>(
             };
 
             let it_is = match annotation_source {
-                TypedIfBranch { index, .. } => format!("The {} branch is", index.ordinal()),
+                TypedIfBranch { .. } => "This branch is".to_string(),
                 TypedWhenBranch { index, .. } => format!("The {} branch is", index.ordinal()),
                 TypedBody { .. } => "The body is".into(),
                 RequiredSymbol { .. } => "The provided type is".into(),
@@ -4667,17 +4667,19 @@ fn type_problem_to_pretty<'b>(
             }
         }
 
-        (IntFloat, _) => alloc.tip().append(alloc.concat([
-            alloc.reflow("You can convert between "),
-            alloc.type_str("Int"),
-            alloc.reflow(" and "),
-            alloc.type_str("Frac"),
-            alloc.reflow(" using functions like "),
-            alloc.symbol_qualified(Symbol::NUM_TO_FRAC),
-            alloc.reflow(" and "),
-            alloc.symbol_qualified(Symbol::NUM_ROUND),
-            alloc.reflow("."),
-        ])),
+        (IntFloat, _) => {
+            alloc.tip().append(alloc.concat(
+                [
+                    alloc.reflow(
+                        "You can convert between integers and fractions using functions like ",
+                    ),
+                    alloc.symbol_qualified(Symbol::NUM_TO_FRAC),
+                    alloc.reflow(" and "),
+                    alloc.symbol_qualified(Symbol::NUM_ROUND),
+                    alloc.reflow("."),
+                ],
+            ))
+        }
 
         (TagsMissing(missing), ExpectationContext::WhenCondition) => match missing.split_last() {
             None => alloc.nil(),

crates/reporting/tests/test_reporting.rs

@@ -1064,8 +1064,8 @@ mod test_reporting {
 
     Every element in a list must have the same type!
 
-    Tip: You can convert between Int and Frac using functions like
-    `Num.toFrac` and `Num.round`.
+    Tip: You can convert between integers and fractions using functions
+    like `Num.toFrac` and `Num.round`.
     "###
     );
 
@@ -1532,16 +1532,16 @@ mod test_reporting {
     5│      x = if Bool.true then 3.14 else 4
                                   ^^^^
 
-    The 1st branch is a fraction of type:
+    This branch is a fraction of type:
 
         Frac *
 
     But the type annotation on `x` says it should be:
 
         Int *
 
-    Tip: You can convert between Int and Frac using functions like
-    `Num.toFrac` and `Num.round`.
+    Tip: You can convert between integers and fractions using functions
+    like `Num.toFrac` and `Num.round`.
     "###
     );
 
@@ -1575,8 +1575,8 @@ mod test_reporting {
 
         Int *
 
-    Tip: You can convert between Int and Frac using functions like
-    `Num.toFrac` and `Num.round`.
+    Tip: You can convert between integers and fractions using functions
+    like `Num.toFrac` and `Num.round`.
     "###
     );
 
@@ -1607,8 +1607,8 @@ mod test_reporting {
 
         Int *
 
-    Tip: You can convert between Int and Frac using functions like
-    `Num.toFrac` and `Num.round`.
+    Tip: You can convert between integers and fractions using functions
+    like `Num.toFrac` and `Num.round`.
     "###
     );
 
@@ -1928,8 +1928,8 @@ mod test_reporting {
 
         { x : Int * }
 
-    Tip: You can convert between Int and Frac using functions like
-    `Num.toFrac` and `Num.round`.
+    Tip: You can convert between integers and fractions using functions
+    like `Num.toFrac` and `Num.round`.
     "###
     );
 
@@ -2485,8 +2485,8 @@ mod test_reporting {
 
         Int *
 
-    Tip: You can convert between Int and Frac using functions like
-    `Num.toFrac` and `Num.round`.
+    Tip: You can convert between integers and fractions using functions
+    like `Num.toFrac` and `Num.round`.
     "###
     );
 
@@ -11001,7 +11001,7 @@ In roc, functions are always written as a lambda, like{}
     5│      f = if Bool.true then {a: ""} else {a: "b", b: ""}
                                   ^^^^^^^
 
-    The 1st branch is a record of type:
+    This branch is a record of type:
 
         { a : Str }
 

www/generate_tutorial/src/tutorial.roc

@@ -2,7 +2,7 @@ app "roc-tutorial"
     packages { pf: "../../../examples/static-site-gen/platform/main.roc" }
     imports [
         pf.Html.{ html, head, body, footer, script, div, main, p, section, h1, h2, label, ol, input, text, nav, a, li, link, meta },
-        pf.Html.Attributes.{ content, name, for, id, type, href, rel, lang, class, title, charset, src },
+        pf.Html.Attributes.{ content, name, for, id, type, href, rel, lang, title, charset, src, role },
     ]
     provides [transformFileContent] to pf
 
@@ -36,9 +36,9 @@ view = \htmlContent ->
 
 viewNavbar : Html.Node
 viewNavbar =
-    div [id "top-bar"] [
+    div [id "top-bar", role "presentation"] [
         nav [] [
-            a [class "home-link", href "/", title "The Roc Programming Language"] [text "roc"],
+            a [id "nav-home-link", href "/", title "The Roc Programming Language"] [text "roc"],
             div [id "top-bar-links"] [
                 a [href "/tutorial"] [text "tutorial"],
                 a [href "https://github.com/roc-lang/roc/tree/main/getting_started"] [text "install"],

www/public/repl/index.html

@@ -17,13 +17,13 @@
 
 <body>
   <div id="top-bar">
-    <nav><a class="home-link" href="/" title="The Roc Programming Language">roc</a>
+    <nav><a id="nav-home-link" href="/" title="The Roc Programming Language">roc</a>
       <div id="top-bar-links"><a href="/tutorial">tutorial</a><a
           href="https://github.com/roc-lang/roc/tree/main/getting_started">install</a><a href="/repl">repl</a><a
           href="/builtins">docs</a></div>
     </nav>
   </div>
-  <main>
+  <main id="repl">
     <h1>The rockin’ Roc REPL</h1>
     <code class="history">
       <div id="help-text"></div>
@@ -33,8 +33,8 @@ <h1>The rockin’ Roc REPL</h1>
       <textarea rows="5" id="source-input" placeholder="You can enter Roc code here once the REPL loads!"
         disabled></textarea>
     </section>
-    </div>
-    <script type="module" src="/repl/repl.js"></script>
+  </main>
+  <script type="module" src="/repl/repl.js"></script>
 </body>
 
 </html>

www/public/repl/repl.css

@@ -153,7 +153,7 @@ li {
     text-align: center;
   }
 
-  main {
+  #repl {
     margin: 0;
     padding: 0;
     min-height: calc(100vh - var(--top-bar-height));

www/public/site.css

@@ -88,7 +88,7 @@ li {
     justify-content: space-between;
 }
 
-#top-bar .home-link {
+#nav-home-link {
     display: flex;
     color: var(--top-bar-fg);
     font-size: 1.8rem;

www/wip_new_website/build-dev-local.sh

@@ -1,14 +1,13 @@
 #!/usr/bin/env bash
 
-# Use this script to for testing the WIP site locally without downloading assets every time. 
+# Use this script to for testing the WIP site locally without downloading assets every time.
 
-# NOTE run `bash www/build.sh` to cache local copy of fonts, and repl assets etc 
+# NOTE run `bash www/build.sh` to cache local copy of fonts, and repl assets etc
 
 rm -rf dist/
+cp -r ../build dist/
 mkdir -p dist/wip
-cp -r ../build/wip/* dist/wip/
 roc run main.roc -- content/ dist/wip/
-cp -r ../build/fonts/ dist/fonts/
 cp -r static/* dist/wip/
 
-simple-http-server -p 8080 --nocache --index -- dist/ 
+simple-http-server -p 8080 --nocache --index -- dist/

www/wip_new_website/content/bdfn.md

@@ -0,0 +1,13 @@
+# BDFN
+
+Hi, I'm [Richard](https://github.com/rtfeldman)! I created Roc in 2018 and am currently its BDFN.
+
+BDFN stands for Benevolent Dictator For Now. There's a whole group of wonderful people collaborating to advance Roc, and we discuss major decisions together before committing to a particular direction. That said, once we reach the point in our discussions where a decision has to be made, I—as BDFN—have the final say...for now.
+
+The difference between BDFN and [Benevolent Dictator For Life](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life) is that I plan to transition away from being in charge of Roc with plenty of time left in my life to watch others take the helm and see how they run things. My last act as BDFN should be to hand over decision-making responsibility to a new system, whatever that ends up being.
+
+Something that needs figuring out between now and then is how to keep the language from growing excessively complex over time. Many committee-driven languages accumulate new features at a rate that would be bad for Roc's long-term health, and I hope we can find a system which minimizes the erosion of simplicity that seems to happen by default.
+
+(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.

www/wip_new_website/content/community.md

@@ -1,41 +1,32 @@
 # Community
 
-WIP
+[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!
 
-## Values 
+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!
 
-<!-- 
-Work in Progress - Richard is developing this section
+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.
 
-Basically it will say something like we expect you to be kind, even if you think someone is being mean to you, don't assume ill intentions etc
--->
-
-## Meet
-
-- Group Chat [roc.zulipchat.com](https://roc.zulipchat.com/)
-- Github Project [roc-lang/roc](https://github.com/roc-lang/roc)
-- Meetups & Events
-
-## Proposals
+## Code of Conduct
 
-- [Good First Issues](https://github.com/roc-lang/roc/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
+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!
 
-<!--
-In this section we want to explain the process, i.e. it's less formal
+## Contributing
 
-TODO finish editing this section
--->
+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).
 
-Roc doesn't have a formal process for managing design proposals. The guiding principal for now is that as a community we should all be friendly, supportive, and openly discuss and sharing ideas.
+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!
 
-There are three loose stages that a design proposal can go through in Roc: Idea, Proposal, and Implementation.
+## Design ideas, feature requests, proposals, etc.
 
-In the Idea stage, people are encouraged to describe their idea and explore the problem, potential solutions, and trade-offs. It is helpful to share the idea in the group chat using the #ideas channel.
+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.
 
-If there is a general consensus that an idea is promising and worth developing, people are encouraged to develop a design Proposal. Some ideas are simple and should progress straight to implementation. However, for more complex Proposals a it write the design into an article or blog post and share it online. This documentation helps in clarifying the proposal and making it more accessible to the community. 
+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.
 
-Implementation using PR...
+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.
 
-## Code of Conduct
+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.
 
-<!-- link to github goes here -->
+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.

www/wip_new_website/content/sponsor.md → www/wip_new_website/content/donate.md

@@ -1,8 +1,8 @@
-# Sponsor
+# Donate
 
 - [Github Sponsorship](https://github.com/sponsors/roc-lang)
 
-<!-- 
+<!--
     1. link to github sponsor
     2. have your company sponsor Roc
- -->
+ -->