Revise welcome post for dataHaskell reboot

Updated the welcome post to reflect the new direction and commitments of dataHaskell, including changes in onboarding, documentation, and community engagement.

Author: mchav

_posts/2016-11-11-welcome-to-datahaskell.markdown

@@ -7,32 +7,22 @@ categories: blog
 
 We’re rebooting dataHaskell! We've collected learnings from the previous dataHaskell effort and decided to revive the effort with a simple promise: make doing data science and machine learning in Haskell feel welcoming, practical, and fast. We've setup an ambitious [roadmap](https://www.datahaskell.org/docs/community/roadmap.html) that we are excited to iterate on in the next two years.
 
-## Why things didn't work out well last time?
-### No single happy path
-We tried to be an umbrella for “data + Haskell” without a default stack that just works. People arrived, asked “how do I start?”, and got five options and a matrix of trade-offs. For data scientists that typically just want something that works this caused a lot of friction. Later there was an effort to create a core set of data haskell libraries (dh-core) but those libraries didn't have much development effort behind them.
+This is still a work in progress with many kinks in both our processes and our software but we are committed to delivering on these goals in the medium to long term.
 
-### Haskell was difficult to set up
-Even seasoned programmers complained about how difficult it was to get Haskell up and running. This meant that there was a lot of churn even before people got to the suggested libraries. This has improved organically because of tools like `ghcup` but there is still work to do in making sure a "dataHaskell stack" works out of the box.
+## What we're doing differently
+* **Single happy path**: We're starting off by building a single, robust happy path that tackles common data science tasks. We will constantly revisit 
+* **Reducing time-to-first-run**: Thoroughly document setup/environment and work with maintainers to fix pain points.
+* **Better documentation**: Produce and encourage thorough documentation using the diataxis framework. Documentation should be runnable so it doesn't drift from implementation.
+* **Clearer ownership**: Named maintainers per repo, issue triaging, and a clear “how to become a maintainer/contributor” guide per repo.
+* **Community**: A predictable heartbeat (e.g., monthly community call, fortnightly “help-wanted” sweep, monthly release notes) for collaboration.
 
-### Not enough story, not enough demos
-People learn by seeing something work. We had links to packages of varying documentation quality but no definitive guides on how to use them.
-
-### Loose collaboration
-Channels existed (Gitter), but there wasn’t a reliable cadence for collaboration so conversations fizzled.
-
-## What's changing this time?
-* We're starting off by building a single, robust happy path that tackles common data science tasks.
-* Thoroughly document setup/environment
-* Produce and encourage thorough documentation using the diataxis framework. Documentation should be runnable so it doesn't drift from implementation.
-* Named maintainers per repo, issue triaging, and a clear “how to become a maintainer/contributor” guide per repo.
-* A predictable heartbeat (e.g., monthly community call, fortnightly “help-wanted” sweep, monthly release notes).
 
 ## Our core values
 Our focus begins with people. A community only grows if it’s safe to be curious, to get things wrong, to ship small and often. We’re rebuilding that culture deliberately: clear on-ramps, friendly discussion, and real projects to gather around.
 
 From there, we’re backing the community with an opinionated stack that favors ease of installation and ease of use over endless choice. Rather than present a buffet of options, we’re holding the bar high for a narrow path that “just works.”
 
-On-boarding will be a first-class concern—both for people who want to use the stack and for people who want to build it. Users should be able to get to a running notebook, load a dataset, and try a model in minutes; contributors should find labeled issues, short feedback loops, and maintainers who make time to review and mentor. We’ll favor copy-paste examples over abstract diagrams, concrete error messages over vague advice, and recipes you can run unchanged on day one. If something takes ten steps, our goal will be to reduce it to three, then to one.
+Onboarding will be a first-class concern—both for people who want to use the stack and for people who want to build it. Users should be able to get to a running notebook, load a dataset, and try a model in minutes; contributors should find labeled issues, short feedback loops, and maintainers who make time to review and mentor. We’ll favor copy-paste examples over abstract diagrams, concrete error messages over vague advice, and recipes you can run unchanged on day one. If something takes ten steps, our goal will be to reduce it to three, then to one.
 
 As we grow, we’ll keep asking the same practical questions: Where are people getting stuck? What’s the smallest change that removes the most friction? Which capabilities unlock real work next—plotting, faster I/O, GPU ergonomics, better docs, friendlier errors? We’ll publish short roadmaps, but we’ll also let usage guide us; the stack should evolve where the community is actually leaning.