Remove legacy script files

CONTRIBUTING.md

@@ -15,7 +15,6 @@ In this page you'll find these guidelines for contributions:
 
 - [How to build the libraries](#how-to-build-the-libraries)
 - [How to generate and validate the documentation](#how-to-generate-and-validate-the-documentation)
-- [How to run the website in your local workspace](#how-to-run-the-website-in-your-local-workspace)
 - [How to propose an improvement](#how-to-propose-an-improvement)
 - [Notes](#notes)
    - [How to upgrade Gradle](#how-to-upgrade-gradle)
@@ -55,7 +54,7 @@ Root project 'arrow'
 +--- Project ':arrow-core'
 ```
 
-2.  Append `:build` after the subproject name and run this task. See also Gradle documentation [how to run subproject tasks.](https://docs.gradle.org/current/userguide/intro_multi_project_builds.html#sec:executing_tasks_by_fully_qualified_name)
+2. Append `:build` after the subproject name and run this task. See also Gradle documentation [how to run subproject tasks.](https://docs.gradle.org/current/userguide/intro_multi_project_builds.html#sec:executing_tasks_by_fully_qualified_name)
 
 ```bash
 ./gradlew :arrow-core:build
@@ -127,19 +126,21 @@ for example
  *  println("value = $someValue")
  *  println("emptyValue = $emptyValue")
  * }
- * ```
+ *
  * <!--- KNIT example-option-01.kt -->
  *  
  * (...)
  */ 
 public sealed class Option<out A> {
+
+}
 ```
 
 #### 2. Snippets for broader samples
 
 If your snippet is showing examples on how to use the public APIs in a broader scenario (like describing FP patterns or similar), then you'll add those snippets to the described docs Markdown file.
 
-## How to propose an improvement 
+## How to propose an improvement
 
 If it's the first time you contribute with a GitHub repository, take a look at [Collaborating with issues and pull requests](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests).
 
@@ -149,11 +150,11 @@ Please, follow the link to [create an issue](https://github.com/arrow-kt/arrow/i
 
 ### How to create a pull request
 
-The easiest way to contribute to Arrow is to create a branch from a fork, and then create a PR on Github from your branch.
+The easiest way to contribute to Arrow is to create a branch from a fork, and then create a PR on GitHub from your branch.
 
 Arrow is a large project that uses several tools to verify that the code is formatted consistently, and that we don't break downstream projects that rely on Arrow's API across versions. 
 
-For code formatting we use [Spotless](https://github.com/diffplug/spotless/tree/main/plugin-gradle) with [KtFmt](https://github.com/facebookincubator/ktfmt) and for API binary compatibility we use [Binary Compatibility Validator](https://github.com/Kotlin/binary-compatibility-validator). They need to run before you commit and push your code to Github.
+For code formatting we use [Spotless](https://github.com/diffplug/spotless/tree/main/plugin-gradle) with [KtFmt](https://github.com/facebookincubator/ktfmt) and for API binary compatibility we use [Binary Compatibility Validator](https://github.com/Kotlin/binary-compatibility-validator). They need to run before you commit and push your code to GitHub.
 
 If you've included those changes for binary compatibility and formatted the code correctly it's time to open your PR and get your contribution into Arrow. Thanks ahead of time for your effort and contributions 🙏
 
@@ -180,7 +181,7 @@ Note: if, when running `build`, you see the following error:
 > Task :arrow-core:apiCheck FAILED
 ```
 
-This means you have changed (advertently or not) some public API. In this case read in the next point below how to resolve this.
+This means you have changed (inadvertently or not) some public API. In this case read in the next point below how to resolve this.
 
 * The approval by 2 maintainers of the Arrow Community.
 
@@ -234,11 +235,11 @@ This will generate updated `.api` files which you can then manually review (if t
 
 Both successful or failed build checks allow to download the tests report to review it:
 
-![how-to-download-tests-report](img/doc/download-report.png)
+![how-to-download-tests-report](static/img/doc/download-report.png)
 
 #### What happens when merging a pull request
 
-When merging the pull request, a new SNAPSHOT library will be published into [Sonatype OSSRH](https://oss.sonatype.org/service/local/repositories/snapshots/content/io/arrow-kt/).
+When merging the pull request, a new SNAPSHOT library will be published into [Sonatype OSS](https://oss.sonatype.org/service/local/repositories/snapshots/content/io/arrow-kt/).
 
 On the other hand, the documentation for the next version (SNAPSHOT) will be updated:
 
@@ -254,7 +255,7 @@ If any of these actions fails, an issue will be created to be solved as soon as
 
 The use of Gradle appears in several subprojects: `arrow-core`, `arrow-stack`, etc.
 
-However, links are being used so it's just necessary to upgrade Gradle in the project root directory:
+However, links are being used, so it's just necessary to upgrade Gradle in the project root directory:
 
 ```
 ./gradlew wrapper --gradle-version <new-version>
@@ -269,16 +270,16 @@ This short guideline provides all the things to keep in mind when adding a new m
   - Add `<module>/build.gradle.kts`
   - Update `settings.gradle.kts`
 - Utilities:
-  - Update BOM file: [build.gradle](arrow-stack/build.gradle)
+  - Update BOM file: [build.gradle](arrow-libs/stack/build.gradle.kts)
 
 ### Gradle dependency configurations
 
-| Configuration | Use | Note |
-| ------------- | --- | ---- |
-| `api` | compilation | exported to consumers for compilation |
-| `implementation` | compilation + runtime | exported to consumers for runtime | 
-| `compileOnly` | just compilation | not exported to consumers | 
-| `runtimeOnly` | just runtime | exported to consumers for runtime | 
-| `testImplementation` | test compilation + test runtime |  | 
-| `testCompileOnly` | test compilation |  | 
-| `testRuntimeOnly` | test runtime |  |
+| Configuration        | Use                             | Note                                  |
+|----------------------|---------------------------------|---------------------------------------|
+| `api`                | compilation                     | exported to consumers for compilation |
+| `implementation`     | compilation + runtime           | exported to consumers for runtime     | 
+| `compileOnly`        | just compilation                | not exported to consumers             | 
+| `runtimeOnly`        | just runtime                    | exported to consumers for runtime     | 
+| `testImplementation` | test compilation + test runtime |                                       | 
+| `testCompileOnly`    | test compilation                |                                       | 
+| `testRuntimeOnly`    | test runtime                    |                                       |

RELEASE.md

@@ -17,8 +17,6 @@ projects.version=0.11.0-SNAPSHOT
 projects.latestVersion=0.10.5
 ```
 2. Update versions in `README.md`
-3. Update versions in [the QuickStart section of the website](arrow-site/docs/docs/quickstart/README.md).
-4. Update versions in [the sidebar](arrow-site/docs/_data/doc-versions.yml).
 
 When merging that pull request, these things will happen automatically:
 
@@ -37,7 +35,7 @@ Then, close and release the Sonatype repository to sync with Maven Central:
 4. Select the staging repository and **Release** to sync with Maven Central
 5. **Drop** and repeat if there are issues.
 
-NOTE: [This plugin](https://github.com/gradle-nexus/publish-plugin) provides tasks for closing and releasing the staging repositories. However, that plugin must be applied to the root project and it would be necessary to discard modules for publication. Let's keep this note here to give it a try later on.
+NOTE: [This plugin](https://github.com/gradle-nexus/publish-plugin) provides tasks for closing and releasing the staging repositories. However, that plugin must be applied to the root project, and it would be necessary to discard modules for publication. Let's keep this note here to give it a try later on.
 
 ### About signing artifacts with GPG/PGP
 
@@ -55,22 +53,20 @@ To verify artifacts during **Close** task, the public key must be distributed to
 Context:
 
 * Latest release has a bug and `main` branch already has other additional features.
-* A released version has a bug and it's not the latest release.
+* A released version has a bug, and it's not the latest release.
 
 How to fix a `<major.minor.patch>` version in some of those contexts:
 
 1. Create `release/<major.minor.(patch + 1)>` branch from tag `<major.minor.patch>`.
 2. Apply the fix into the new branch:
    * Via pull request for new changes.
    * Directly for existing changes (cherry-pick).
-3. Check that new `<major.minor.(patch + 1)-SNAPSHOT>` artifacts are deployed into [Sonatype OSSRH](https://oss.sonatype.org/service/local/repositories/snapshots/content/io/arrow-kt/) with the fixes.
+3. Check that new `<major.minor.(patch + 1)-SNAPSHOT>` artifacts are deployed into [Sonatype OSS](https://oss.sonatype.org/service/local/repositories/snapshots/content/io/arrow-kt/) with the fixes.
 4. Try the new `<major.minor.(patch + 1)-SNAPSHOT>` version.
 5. Create a pull request into `main` branch if the fix must be applied to the new versions as well.
 6. Create a pull request into `release/<major.minor.(patch + 1)>` branch to release the fix:
     * Change just `projects.latestVersion` in `arrow-libs/gradle.properties`.
     * Update the version in `README.md`.
-    * Update the version in [the QuickStart section of the website](arrow-site/docs/docs/quickstart/README.md).
-    * Update [the sidebar](arrow-site/docs/_data/doc-versions.yml).
 
 What will happen when merging the last pull request?
 
@@ -81,7 +77,3 @@ What will happen when merging the last pull request?
 TODO: Release notes and GitHub release must be created manually.
 
 Then, close and release the Sonatype repository to sync with Maven Central in the same way as other versions.
-
-Last step:
-
-* Update [the sidebar](arrow-site/docs/_data/doc-versions.yml) in the `main` branch to show the new latest version for `major.minor`.