Fixed code typos and broken link

Author: Gullumluvl

design-patterns/branch-and-merge/index.md

@@ -34,7 +34,7 @@ workflow run {
 
   # Run `stepD`, connecting the `in1` input to `stepB`'s `out` output
   # and the `in2` input to `stepC`'s `out` output.
-  call stepC { input: in1 = stepB.out, in2 = stepC.out }
+  call stepD { input: in1 = stepB.out, in2 = stepC.out }
 }
 ```
 
@@ -143,7 +143,7 @@ workflow run {
   # (b) The merge happens here.
   call merge_vcfs { input:
     snp_vcf = filter_snps.filtered_vcf,
-    indel_vcf = filter_snps.filtered_vcf,
+    indel_vcf = filter_indels.filtered_vcf,
   }
 
   output {

design-patterns/conditional-statement/index.md

@@ -4,7 +4,7 @@ It is often desirable to only execute some section of a computation graph only i
 particular condition holds. This could be as simple as a user input to the workflow
 indicating the "mode A" should be run instead of "mode B", whether to scatter and gather
 tasks rather than running a single multi-threaded task, or enabling an entire analysis
-based on if some analytical check passes a QC threshold. In these cases, you'll want to
+based on whether some analytical check passes a QC threshold. In these cases, you'll want to
 reach for **conditional statements** (also known as `if`/`else` statements).
 
 ![A diagram showing three tasks: `stepA`, `stepB`, and `stepC`. `stepA` is always

getting-started/quickstart.md

@@ -116,7 +116,7 @@ the output of the above workflow would be the following.
     "Hello, world!",
     "Hallo, world!",
     "Hej, world!",
-    // "Ahoy, world!" is included is `is_pirate` is set to `true` above.
+    // "Ahoy, world!" is included if `is_pirate` is set to `true` above.
   ]
 }
 ```

language-guide/tasks.md

@@ -9,10 +9,10 @@ Fundamentally, the represent a bash script that is intended to be run to accompl
 goal. You'll reach for tasks when defining each of the constituent analyses within a
 broader [workflow](./workflows.md).
 
-Tasks have a required ```command``` section and several optional sections for things
+Tasks have a required `command` section and several optional sections for things
 like defining inputs, defining outputs, documenting your task, and specifying runtime
 requirements. We'll cover each of these in detail here while leaving an exhaustive
-explanation to [the specification][spec-tasks]. 
+explanation to [the specification][spec-tasks].
 
 Below is a representative example of what a simple task might look like.
 
@@ -179,7 +179,7 @@ them when the need arises.
 
 [spec-tasks]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#task-definition
 [spec-task-inputs]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#task-inputs
-[spec-task-inputs]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#task-outputs
+[spec-task-outputs]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#task-outputs
 [spec-requirements]:
     https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#-requirements-section
 [spec-requirements-attributes]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#requirements-attributes