- [ ] Provide unit tests (under `<subproject>/src/test`) to verify logic.
- [ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes.
- [ ] Ensure that tests pass sanity check: `./gradlew sanityCheck`.
- [ ] Ensure that tests pass locally: `./gradlew <changed-subproject>:quickTest`.

### Reviewing cheatsheet

    FileTree getSource() {
        return super.getSource();
    }

    @TaskAction
    def extract() {
        Date start = new Date()

        //parsing all input files into metadata
        //and placing them in the repository object

    vcs.useAbsoluteVcs(VersionedSettingsBranch.fromDslContext().vcsRootId())

    features {
        freeDiskSpace {
            // Lower the limit such that the agent work directories aren't cleaned during the AMI baking process
            requiredSpace = "100mb"
        }
    }

    params {
        param("defaultBranchName", "master")
        param("env.JAVA_HOME", javaHome(BuildToolBuildJvm, Os.LINUX))
    }

        <automation id="summary_table/summary_table"/>`;

    console.log("summaryTable: " + result);
    return result;
}

function platformsAffected(statistics) {
    // Significance is defined as a platform having more than 10% of the total lines changed
    let totalLinesChanged = statistics.reduce((acc, summary) => acc + summary.additions + summary.deletions, 0);
    let platformHasSignificantChanges = function(summary) {

For any non-trivial change, we need to be able to answer these questions:

* Why is this change done? What's the use case?
* For user facing features, what will the API look like?
* What test cases should it have? What could go wrong?
* How will it roughly be implemented? We'll happily provide code pointers to save you time.

For now we just have this global repository of ADRs.
If we see fit, we can break these out to per-platform ones, or keep a hybrid approach to having global and platform-specific ADSs.

Our aim is to keep the process lightweight and approachable.