[docs] fix docs snippet and markdown content

- Add code snippet for backfill config in `dagster.yaml`
- Remove redundant section in `workspace-yaml.md`
- Fix markdown table

Author: jjyeo

docs/docs/dagster-basics-tutorial/6-custom-components.md

@@ -10,7 +10,7 @@ If we think about the code for our three assets (`customers`, `orders`, and `pay
 
 These assets are a great candidate for a [custom component](/guides/build/components/creating-new-components). Components generate `Definitions` through a configuration layer. There are built-in components that let you integrate with common workflows (such as turning Python scripts into assets), or dynamically generate `Definitions` for tools like [dbt](/integrations/libraries/dbt) or [Fivetran](/integrations/libraries/fivetran). With custom components, you can define your own specific use cases.
 
-In this step, you will use a custom component to streamline the development of similar assets and replace their `Definitions` in your project with a Component that can generate them from a a YAML configuration file instead.
+In this step, you will use a custom component to streamline the development of similar assets and replace their `Definitions` in your project with a Component that can generate them from a YAML configuration file instead.
 
 ![2048 resolution](/images/tutorial/dagster-tutorial/overviews/components.png)
 

docs/docs/deployment/oss/oss-deployment-architecture.md

@@ -47,12 +47,12 @@ Dagster's provided [Kubernetes Helm chart deployment](/deployment/oss/deployment
 
 Job execution flows through several parts of the Dagster system. The following table describes runs launched by the UI, specifically the components that handle execution and the order in which they are executed.
 
-| Order                                                     | Component                                                                                                                                                                                                                                                   | Description | Configured by |
-| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------- |
-| [Run coordinator](/deployment/execution/run-coordinators) | The run coordinator is a class invoked by the webserver process when runs are launched from the Dagster UI. This class can be configured to pass runs to the daemon via a queue.                                                                            | Instance    |
-| [Run launcher](/deployment/execution/run-launchers)       | The run launcher is a class invoked by the daemon when it receives a run from the queue. This class initializes a new run worker to handle execution. Depending on the launcher, this could mean spinning up a new process, container, Kubernetes pod, etc. | Instance    |
-| Run worker                                                | The run worker is a process which traverses a graph and uses the executor to execute each op.                                                                                                                                                               | n/a         |
-| [Executor](/guides/operate/run-executors)                 | The executor is a class invoked by the run worker for running user ops. Depending on the executor, ops run in local processes, new containers, Kubernetes pods, etc.                                                                                        | Run config  |
+| Order |  Component                                                | Description                                                                                                                                                                                                                                                 | Configured by |
+| ----- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
+| 1     | [Run coordinator](/deployment/execution/run-coordinators) | The run coordinator is a class invoked by the webserver process when runs are launched from the Dagster UI. This class can be configured to pass runs to the daemon via a queue.                                                                            | Instance      |
+| 2     | [Run launcher](/deployment/execution/run-launchers)       | The run launcher is a class invoked by the daemon when it receives a run from the queue. This class initializes a new run worker to handle execution. Depending on the launcher, this could mean spinning up a new process, container, Kubernetes pod, etc. | Instance      |
+| 3     | Run worker                                                | The run worker is a process which traverses a graph and uses the executor to execute each op.                                                                                                                                                               | n/a           |
+| 4     | [Executor](/guides/operate/run-executors)                 | The executor is a class invoked by the run worker for running user ops. Depending on the executor, ops run in local processes, new containers, Kubernetes pods, etc.                                                                                        | Run config    |
 
 Additionally, note that runs launched by schedules and sensors go through the same flow, but the first step is called by the [Dagster daemon](/deployment/execution/dagster-daemon) instead of the webserver.
 

docs/docs/guides/build/projects/workspaces/workspace-yaml.md

@@ -32,16 +32,6 @@ To accommodate incrementally migrating from `@repository` to `Definitions`, code
 
 :::
 
-## Location of workspace.yaml
-
-Dagster command-line tools (like `dg`) look for workspace files in the current directory when invoked. This allows you to launch from that directory without the need for command line arguments
-
-To load the workspace.yaml file from a different folder, use the -w argument:
-
-```bash
-dg dev -w path/to/workspace.yaml
-```
-
 ## File structure
 
 The `workspace.yaml` file uses the following structure:

examples/docs_snippets/docs_snippets/deploying/dagster_instance/dagster.yaml

@@ -410,6 +410,14 @@ schedules:
 
 # end_marker_schedules
 
+# start_marker_backfills
+
+backfills:
+  use_threads: true
+  num_workers: 8
+
+# end_marker_backfills
+
 auto_materialize:
   run_tags:
     key: value