Merge WDL 1.1.2 changes, fix broken links (#650)

openwdl · May 23, 2024 · 0714e91 · 0714e91
1 parent 32cb760
commit 0714e91
Show file tree

Hide file tree

Showing 9 changed files with 125 additions and 117 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -17,31 +17,6 @@ Keep the changelog pleasant to read in the text editor:
 + Properly indent blocks.
 -->
 
-version development
----------------------------
-
-+ Fixed description of ternary operator to say that the type, not the value,
-  of the if-then-else is the same regardless of which side is evaluated.
-  [PR 476](https://github.com/openwdl/wdl/pull/476) by @notestaff
-
-+ Lexer rule BeginWhitespace now matches non-empty string.
-  [PR 440](https://github.com/openwdl/wdl/pull/440) by @yunhailuo
-
-+ Runtime section no longer accepts arbitrary keys. Added new hints section for arbitrary runtime hints.
-  [PR 315](https://github.com/openwdl/wdl/pull/315) by @patmagee
-
-+ Removes string interpolator options. 
-  [PR 229](https://github.com/openwdl/wdl/pull/229) and [PR 368](https://github.com/openwdl/wdl/pull/366) 
-  by @EvanTheB and @illusional. 
-
-+ `Object` has been removed from WDL. `struct` can be used to achieve the same
-  type of functionality in a more explicit way.
-  [PR 283](https://github.com/openwdl/wdl/pull/283) by @patmagee.
-
-+ Added a new `Directory` type to make it easier when working with inputs that
-  consist of multiple files.
-  [PR 241](https://github.com/openwdl/wdl/pull/241) by @cjllanwarne.
-
 version 1.2.0
 ---------------------------
 
@@ -109,6 +84,22 @@ version 1.2.0
 
 + Clarified that accessing a non-existent member of an object, struct, or call is an error.
 
+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
 ---------------------------
 
@@ -139,7 +130,7 @@ version 1.1.1
 version 1.1.0
 ---------------------------
 
-+ Added [Errata](versions/1.1/Errata.md).
++ Added [Errata](https://github.com/openwdl/wdl/blob/main/versions/1.1/Errata.md).
 
 + Clarified that the `sub` function requires a POSIX Extended Regular Expression (ERE).
   [PR 243](https://github.com/openwdl/wdl/pull/243) by @rhpvorderman

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -9,11 +9,11 @@ I understand that WDL is a community-driven standard. Any ideas or suggestions I
 # How to contribute
 ## Contributions to WDL discussions
 
-WDL is the bioinformatics workflow language meant to be written and read by humans. In order to achieve this goal we rely on actual humans to help keep us on the right course.  Fellow WDL enthusiasts debate the finer points of syntax over in the [WDL developers forum](FIXME) and everyone is invited to participate. You'll need to register yourself to participate in the forum.
+WDL is the bioinformatics workflow language meant to be written and read by humans. In order to achieve this goal we rely on actual humans to help keep us on the right course. Fellow WDL enthusiasts debate the finer points of syntax in the [WDL Slack](https://join.slack.com/t/openwdl/shared_invite/zt-ctmj4mhf-cFBNxIiZYs6SY9HgM9UAVw) and everyone is invited to participate (registration required).
 
 ## Contributions to the WDL ecosystem
 
-As WDL increases in popularity, a number of people are [building tools](https://software.broadinstitute.org/wdl/toolkit) to make it easier to interact with WDL or platforms that support it. If you've created something which you think would be useful we'd love to hear about it! We can help you help us help everyone.
+As WDL increases in popularity, a number of people are [building tools](README.md#software-and-tools) to make it easier to interact with WDL or platforms that support it. If you've created something which you think would be useful we'd love to hear about it! We can help you help us help everyone.
 
 ## Contributions to the documentation, code, etc
 

diff --git a/GOVERNANCE.md b/GOVERNANCE.md
@@ -6,20 +6,19 @@ WDL has a community-driven development process where most decisions are made thr
 
 Current core team members are:
 
-| Name               | Organization            | github                  |
-|:-------------------|:-------------|:------------------
-| Jeff Gentry        | Fulcrum Genomics                 | [geoffjentry](https://github.com/geoffjentry) |
-| Mike Lin           | Chan Zuckerberg Initiative        | [mlin](https://github.com/mlin) |
-| Patrick Magee      | DNAstack                        | [patmagee](https://github.com/patmagee) |
-| Brian O'Connor     | University of California, Santa Cruz | [briandoconnor](https://github.com/briandoconnor) |
-| Geraldine Van der Auwera | Broad Institute | [vdauwera](https://github.com/vdauwera) |
-| 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) |
-| Ruben Vorderman | Leiden University Medical Center | [rhpvorderman](https://github.com/rhpvorderman) |
-| Venkat Malladi | Microsoft | [vsmalladi](https://github.com/vsmalladi) |
-
+| Name                  | Organization                         | github                                            |
+| :-------------------- | :----------------------------------- | :------------------------------------------------ |
+| John Didion           | Fulcrum Genomics                     | [jdidion](https://github.com/jdidion)             |
+| Taylor Firman         | Fred Hutch                           | [tefirman](https://github.com/tefirman)           |
+| Michael Franklin      | Centre for Population Genomics       | [illusional](https://github.com/illusional)       |
+| Jeff Gentry           | Fulcrum Genomics                     | [geoffjentry](https://github.com/geoffjentry)     |
+| Mike Lin              | Chan Zuckerberg Initiative           | [mlin](https://github.com/mlin)                   |
+| Christopher Llanwarne | Broad Institute                      | [cjllanwarne](https://github.com/cjllanwarne)     |
+| Patrick Magee         | DNAstack                             | [patmagee](https://github.com/patmagee)           |
+| Venkat Malladi        | Microsoft                            | [vsmalladi](https://github.com/vsmalladi)         |
+| Brian O'Connor        | University of California, Santa Cruz | [briandoconnor](https://github.com/briandoconnor) |
+| Lee Pang              | Amazon                               | [wleepang](https://github.com/wleepang)           |
+| Ruben Vorderman       | Leiden University Medical Center     | [rhpvorderman](https://github.com/rhpvorderman)   |
 
 At the core group's discretion a new member may be added by a majority vote. This addition will be done to recognize **significant** contributions to the community. *Contributions* include such things as:
 

diff --git a/README.md b/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.
 
@@ -65,7 +65,7 @@ The WDL community also has an official [blog](https://dev.to/openwdl) where anno
 
 - [wdl-docs](https://docs.openwdl.org/en/stable/)
 - [learn-wdl](https://github.com/openwdl/learn-wdl)
-- [WDL Resources](https://support.terra.bio/hc/en-us/sections/360007274612-WDL-Documentation) provided by Terra (a product of the Broad Institute)
+- [WDL Resources](https://support.terra.bio/hc/en-us/sections/360007274612-WDL-Resources) provided by Terra (a product of the Broad Institute)
 
 ## Published Workflows 
 

diff --git a/RFC.md b/RFC.md
@@ -3,13 +3,14 @@ RFC Process
 
 Most technical decisions are decided through the "RFC" ([Request for Comments](https://en.wikipedia.org/wiki/Request_for_Comments)) process. Small changes, such as minor grammatical edits to the specification, do not need to need to follow the RFC process. However, if one intends to make a substantive change to the WDL specification , the following process should be adhered to:
 
- 1. Ideally have an informal discussion of the topic on [Slack](https://join.slack.com/t/openwdl/shared_invite/zt-ctmj4mhf-cFBNxIiZYs6SY9HgM9UAVw) and/or [GitHub discussions](https://github.com/openwdl/wdl/discussions) in order to gauge basic viability. As a rule of thumb, receiving encouraging feedback from long-standing community members is a good indication that the RFC is worth pursuing.
- 2. Write up a formal proposal, including requested changes to the current specification, as a pull request on GitHub
- 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.
+1. Ideally have an informal discussion of the topic on [Slack](https://join.slack.com/t/openwdl/shared_invite/zt-ctmj4mhf-cFBNxIiZYs6SY9HgM9UAVw) and/or [GitHub discussions](https://github.com/openwdl/wdl/discussions) in order to gauge basic viability. As a rule of thumb, receiving encouraging feedback from long-standing community members is a good indication that the RFC is worth pursuing.
+2. Write up a formal proposal, including requested changes to the current specification, as a pull request on GitHub
+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. 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.