Add Toil to README

CHANGELOG.md

@@ -42,6 +42,22 @@ version development
   consist of multiple files.
   [PR 241](https://github.com/openwdl/wdl/pull/241) by @cjllanwarne.
 
+version 1.1.2
+---------------------------
+
++ State that `Union` is also the type of some `runtime` attributes.
+
++ Remove some syntax sections that were missed in 1.1.1.
+
++ Clarify short-circuiting of boolean expressions (#199)
+
++ Added requirement for tests to the RFC
+
++ Clarifies number of sections allowed within `task` and `workflow` blocks.
+  [PR 598](https://github.com/openwdl/wdl/pull/598) by @claymcleod
+
++ Clarified that `read_bool` is case-insensitive, and added an example.
+
 version 1.1.1
 ---------------------------
 

GOVERNANCE.md

@@ -16,7 +16,7 @@ Current core team members are:
 | Christopher Llanwarne | Broad Institute | [cjllanwarne](https://github.com/cjllanwarne) |
 | John Didion | Fulcrum Genomics | [jdidion](https://github.com/jdidion) |
 | Michael Franklin | Centre for Population Genomics | [illusional](https://github.com/illusional) |
-| Amy Paguirigan | Fred Hutch | [vortexing](https://github.com/vortexing) |
+| Taylor Firman | Fred Hutch | [tefirman](https://github.com/tefirman) |
 | Ruben Vorderman | Leiden University Medical Center | [rhpvorderman](https://github.com/rhpvorderman) |
 | Venkat Malladi | Microsoft | [vsmalladi](https://github.com/vsmalladi) |
 

README.md

@@ -2,7 +2,7 @@
 
 The **Workflow Description Language (WDL)** is an open standard for describing data processing workflows with a human-readable and writeable syntax.
 WDL makes it straightforward to define analysis tasks, connect them together in workflows, and parallelize their execution.
-The language strives to be accessible and understantable to all manner of users, including programmers, analysts, and operators of a production system.
+The language strives to be accessible and understandable to all manner of users, including programmers, analysts, and operators of a production system.
 The language enables common patterns, such as scatter-gather and conditional execution, to be expressed simply.
 WDL is designed for portability, and there are several [implementations](#execution-engines-and-platforms) to choose from that run in a variety of environments, including HPC systems and cloud platforms.
 
@@ -14,7 +14,7 @@ The WDL *language* has a two-number version (e.g., `1.1`).
 An increase in the minor (second) version number (e.g., `1.0` to `1.1`) indicates the addition of, or non-breaking changes to, the language or standard library functions.
 An increase in the major (first) version number (e.g., `1.0` to `2.0`) indicates that breaking changes have been made.
 
-The WDL *specification* has a three-number version (e.g., `1.1.1`).
+The WDL *specification* has a three-number version (e.g., `1.1.2`).
 The specification version tracks the language version, but there may also be patch releases (indicated by a change to the patch, or third, version number) that include fixes for typos, additional examples, or non-breaking clarifications of ambiguous language.
 
 ## Language Specifications
@@ -97,6 +97,7 @@ Please see the documentation associated with each tool/platform for information
 | [dxCompiler](https://github.com/dnanexus/dxCompiler)                           | Yes                   | No              | No    | DNAnexus              |
 | [MiniWDL](https://github.com/chanzuckerberg/miniwdl)                           | Yes                   | Yes             | SLURM | AWS Batch             |
 | [Terra](https://terra.bio/)                                                    | No                    | No              | No    | Azure, GCP            |
+| [Toil](https://toil.readthedocs.io/en/master/wdl/introduction.html)            | Yes                   | Yes             | Many  | GCP, AWS, WES         |
 
 \* Also see [WDL Runner](https://github.com/broadinstitute/wdl-runner), a script for launch WDL workflows on GCP using Cromwell
 

RFC.md

@@ -8,8 +8,9 @@ Most technical decisions are decided through the "RFC" ([Request for Comments](h
  3. A core team member will be assigned as the *shepherd* of this RFC. The shepherd shall be responsible for keeping the discussion moving and ensuring all concerns are responded to.
  4. Work to build broad support from the community. Encouraging people to comment, show support, show dissent, etc. Ultimately the level of community support for a change will decide its fate. 
  5. RFCs rarely go through this process unchanged, especially as alternatives and drawbacks are discovered. You can make edits to the RFC to clarify or change the design, but make changes as new commits to the pull request, and leave a comment on the pull request explaining your changes. Specifically, do not squash or rebase commits after they are visible on the pull request.
- 6. When it appears that a discussion is no longer progressing in a constructive way, or a general consensus has been reached, the shepherd will make an official summary on where the consensus has wound up.
- 7. The shepherd will put out an official call for votes. This call shall be advertised broadly and will last ten calendar days. Any interested member may vote via +1/-1.
- 8. After the voting process is complete the core group shall decide to officially approve this RFC. It is expected that barring extreme circumstances this is a rubber stamp of the voting process. An example of an exceptional case would be if representatives for every WDL implementation vote against the feature for feasibility reasons.
+ 6. Every significant addition or change to the spec will require a test case to be accepted. See the [testing README](tests/README.md) for details on how to write tests.
+ 7. When it appears that a discussion is no longer progressing in a constructive way, or a general consensus has been reached, the shepherd will make an official summary on where the consensus has wound up.
+ 8. The shepherd will put out an official call for votes. This call shall be advertised broadly and will last ten calendar days. Any interested member may vote via +1/-1.
+ 9. After the voting process is complete the core group shall decide to officially approve this RFC. It is expected that barring extreme circumstances this is a rubber stamp of the voting process. An example of an exceptional case would be if representatives for every WDL implementation vote against the feature for feasibility reasons.
 
 When an RFC is approved it will become part of the current draft version of the specification. This will allow time for implementers to verify feasibility and cutting edge users  to get used to the new syntax. In order to prevent untested features from entering into an official specification version at least one WDL implementation must support a feature before it’s allowed to be merged into the current draft version.