🚚 Move data documentation files from Data/ to root directory

Data/Analytics Engineering.md Analytics Engineering.md

···
   - [More analysis might not be the best solution if you can't validate or take actions on previous analysis](https://twitter.com/ejames_c/status/1753692862548697464)!
 - Accept that [analytics is a mess](https://benn.substack.com/p/analytics-is-a-mess).
   - Explicitly create separate workspaces for curated (production) and messy (experimental) work.
-- Reports are rarely read, and often forgotten. [[Data Culture|Decision-making involves getting data, summarizing and predicting ad then taking action]].
-  - One of the best ways to communicate data is telling stories. Stories are more captative and present a coherent view around a topic.
+- Reports are rarely read, and often forgotten. [[Data Culture|Decision-making involves getting data, summarizing and predicting and then taking action]].
+  - One of the best ways to communicate data is telling stories. Stories are more captivating and present a coherent view around a topic.
 - [The analytics engineer workload is a lot like being a data librarian](https://www.youtube.com/watch?v=T0Z_ibd3Hx0).
   - If you are running a library you have these books coming in and you have people who are looking for books on specific topics and you've got to figure out a way to organize all those books so that all those people can find what they need. There are many different ways to organize books, not just one perfect solution. A librarian is interested in helping people find the books that they're looking for but also discovering new books that they didn't realize that they were looking for.
 - [Analytics code should be version controlled, tested, modular and maintainable](https://www.getdbt.com/analytics-engineering/why/).
···
 - [Skrimmage](https://github.com/Skrimmage/Data-Platform)
 - [Ibis](https://github.com/ibis-project/ibis-analytics)
 - [OSO](https://github.com/opensource-observer/oso)
-- [Tuba](https://github.com/tuva-health/tuva)
+- [Tuva](https://github.com/tuva-health/tuva)
 - [Department of Education for New South Wales](https://github.com/wisemuffin/nsw-doe-data-stack-in-a-box)
-- [OP Analytitcs](https://github.com/ethereum-optimism/op-analytics)
+- [OP Analytics](https://github.com/ethereum-optimism/op-analytics)
 - [Transfermarkt Datasets](https://github.com/dcaribou/transfermarkt-datasets)
 - [OpenTimes](https://github.com/dfsnow/opentimes)
 

Data/Data Engineering.md Data Engineering.md

···
 
 - **Simplicity**: Each steps is easy to understand and modify. Rely on immutable data. Write only. No deletes. No updates. Avoid having too much "state". Hosting static files on S3 is much less friction and maintenance than a server somewhere serving an API.
 - **Reliability**: Errors in the pipelines can be recovered. Pipelines are monitored and tested. Data is saved in each step (storage is cheap) so it can be used later if needed. For example, adding a new column to a table can be done extracting the column from the intermediary data without having to query the data source. It is better to support 1 feature that works reliably and has a great UX than 2 that are unreliable or hard to use. One solid step is better than 2 finicky ones.
-- **[[Modularity]]**: Steps are independent, declarative, and [[Idempotence|itempotent]]. This makes pipelines composable.
+- **[[Modularity]]**: Steps are independent, declarative, and [[Idempotence|idempotent]]. This makes pipelines composable.
 - **Consistency**: Same conventions and design patterns across pipelines. If a failure is actionable by the user, clearly let them know what they can do. Schema on write as there is always a schema.
 - **Efficiency**: Low event latency when needed. Easy to scale up and down. A user should not be able to configure something that will not work. Don't mix heterogeneous workloads under the same tooling (e.g: big data warehouses doing simple queries 95% of their time and 1 big batch once a day).
 - **Flexibility**: Steps change to conform data points. Changes don't stop the pipeline or losses data. Fail fast and upstream.

Data/Data Practices.md Data Practices.md

···
 - People need to prepare and that means better kickoff conversation.
 - Easier to triage and connect dots across requests.
 - Creates easily referenced records of requests.
-- Friction cuts down on lazy asks. Too much friction will disuade legit ask.
+- Friction cuts down on lazy asks. Too much friction will dissuade legit ask.
 
 ### Data Request Form