-
-
-Now that we have the approval of the feature's author, we can get to work!
-
-## 2. Set up
-
-Hacking Scala begins with creating a branch for your work item. To develop Scala we use [Git](https://git-scm.com/)
-and [GitHub](https://github.com/). This section of the guide provides a short walkthrough, but if you are new to Git,
-it probably makes sense to familiarize yourself with Git first. We recommend
-
-* the [Git Pro](https://git-scm.com/book/en/) online book.
-* the help page on [Forking a Git Repository](https://help.github.com/articles/fork-a-repo).
-* this great training tool [LearnGitBranching](https://pcottle.github.io/learnGitBranching/). One hour hands-on training helps more than 1000 hours reading.
-
-### Fork
-
-Log into [GitHub](https://github.com/), go to [https://github.com/scala/scala](https://github.com/scala/scala) and click the `Fork`
-button in the top right corner of the page. This will create your own copy of our repository that will serve as a scratchpad for your work.
-
-If you're new to Git, don't be afraid of messing up-- there is no way you can corrupt our repository.
-
-
-
-### Clone
-
-If everything went okay, you will be redirected to your own fork at `https://github.com/user-name/scala`, where `username`
-is your GitHub user name. You might find it helpful to read [https://help.github.com/fork-a-repo/](https://help.github.com/fork-a-repo/),
-which covers some of the things that will follow below. Then, _clone_ your repository (i.e. pull a copy from GitHub to your local machine) by running the following on the command line:
-
- 16:35 ~/Projects$ git clone https://github.com/xeno-by/scala
- Cloning into 'scala'...
- remote: Counting objects: 258564, done.
- remote: Compressing objects: 100% (58239/58239), done.
- remote: Total 258564 (delta 182155), reused 254094 (delta 178356)
- Receiving objects: 100% (258564/258564), 46.91 MiB | 700 KiB/s, done.
- Resolving deltas: 100% (182155/182155), done.
-
-This will create a local directory called `scala`, which contains a clone of your own copy of our repository. The changes that you make
-in this directory can be propagated back to your copy hosted on GitHub and, ultimately, pushed into Scala when your patch is ready.
-
-### Branch
-
-Before you start making changes, always create your own branch. Never work on the `master` branch. Think of a name that describes
-the changes you plan on making. Use a prefix that describes the nature of your change. There are essentially two kinds of changes:
-bug fixes and new features.
-
-* For bug fixes, use `issue/NNNN` or `ticket/NNNN` for bug NNNN from the [Scala bug tracker](https://github.com/scala/bug).
-* For new feature use `topic/XXX` for feature XXX. Use feature names that make sense in the context of the whole Scala project and not just to you personally. For example, if you work on diagrams in Scaladoc, use `topic/scaladoc-diagrams` instead of just `topic/diagrams` would be a good branch name.
-
-Since in our example, we're going to fix an existing bug [6725](https://github.com/scala/bug/issues/6725), we'll create a branch named `ticket/6725`.
-
- 16:39 ~/Projects/scala (master)$ git checkout -b ticket/6725
- Switched to a new branch 'ticket/6725'
-
-If you are new to Git and branching, read the [Branching Chapter](https://git-scm.com/book/en/Git-Branching) in the Git Pro book.
-
-### Build
-
-The next step after cloning your fork is setting up your machine to build Scala.
-
-You need the following tools:
-
-* A Java SDK. The baseline version is 6 for 2.11.x and 8 for 2.12.x. It's possible to use a later SDK for local development, but the continuous integration builds will verify against the baseline version.
-* `sbt`, an interactive build tool commonly used in Scala projects. Acquiring sbt manually is not necessary -- the recommended approach is to download the [sbt-extras runner script](https://github.com/paulp/sbt-extras/blob/master/sbt) and use it in place of `sbt`. The script will download and run the correct version of sbt when run from the Scala repository's root directory.
-* `curl` -- the build uses `curl` in the `pull-binary-libs.sh` script to download bootstrap libs.
-
-OS X and Linux builds should work. Windows is supported, but it might have issues. Please report to the [Scala bug tracker](https://github.com/scala/bug) if you encounter any.
-
-Building Scala is as easy as running `sbt dist/mkPack` in the root of your cloned repository. In general, it's much more efficient to enter the `sbt` shell once and run the various tasks from there, instead of running each task by launching `sbt some-task` on your command prompt.
-
-Be prepared to wait for a while -- a full "clean" build takes 5+ minutes depending on your machine (longer on older machines with less memory). On a recent laptop, incremental builds usually complete within 10-30 seconds.
-
-### IDE
-
-There's no single editor of choice for working with Scala sources, as there are trade-offs associated with each available tool.
-
-Both Eclipse and IntelliJ IDEA have Scala plugins, which are known to work with our codebase.
-Both of those Scala plugins provide navigation, refactoring, error reporting functionality, and integrated debugging.
-See [the Scala README](https://github.com/scala/scala#ide-setup) for instructions on using Eclipse and IntelliJ IDEA with the Scala repository.
-
-There also exist lighter-weight editors such as Emacs, Sublime or jEdit which are faster and much less memory/compute-intensive to run, while
-lacking semantic services and debugging. To address this shortcoming, they can integrate with ENSIME,
-a helper program, which hosts a resident Scala compiler providing some of the features implemented in traditional IDEs. However despite
-having significantly matured over the last year, support for our particular code base is still being improved, and is not as mature as for Eclipse and IntelliJ.
-
-Due to the immense variability in personal preference between IDE/editor experience, it's difficult to recommend a particular tool, and your choice should boil down to your personal preferences.
-
-## 3. Hack
-
-When hacking on your topic of choice, you'll be modifying Scala, compiling it and testing it on relevant input files.
-Typically you would want to first make sure that your changes work on a small example and afterwards verify that nothing break
-by running a comprehensive test suite.
-
-We'll start by creating a `sandbox` directory (`./sandbox` is listed in the .gitignore of the Scala repository), which will hold a single test file and its compilation results. First, let's make sure that
-[the bug](https://github.com/scala/bug/issues/6725) is indeed reproducible by putting together a simple test and compiling and running it with the Scala compiler that we built using `sbt`. The Scala compiler that we just built is located in `build/pack/bin`.
-
- 17:25 ~/Projects/scala (ticket/6725)$ mkdir sandbox
- 17:26 ~/Projects/scala (ticket/6725)$ cd sandbox
- 17:26 ~/Projects/scala/sandbox (ticket/6725)$ edit Test.scala
- 17:26 ~/Projects/scala/sandbox (ticket/6725)$ cat Test.scala
- object Test extends App {
- val a = 1
- val s = f"$a%s%n$a%s"
- println(s)
- }
- 17:27 ~/Projects/scala/sandbox (ticket/6725)$ ../build/pack/bin/scalac Test.scala
- 17:28 ~/Projects/scala/sandbox (ticket/6725)$ ../build/pack/bin/scala Test
- 1%n1 // %n should've been replaced by a newline here
-
-### Implement
-
-Now, implement your bugfix or new feature!
-
-Here are also some tips & tricks that have proven useful in Scala development:
-
-* After building your working copy with the `compile` sbt task, there's no need to leave the comfort of your sbt shell to try it out: the REPL is available as the `scala` task, and you can also run the compiler using the `scalac` task. If you prefer to run the REPL outside sbt, you can generate the scripts in `build/quick/bin` using the `dist/mkQuick` task.
-* The sbt workflow is also great for debugging, as you can simply create a remote debugging session in your favorite IDE, and then activate the JVM options for the next time you run the `scala` or `scalac` tasks using:
-
-```
-> set javaOptions in compiler := List("-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8002")
-> scalac test.scala
-[info] Running scala.tools.nsc.Main -usejavacp test.scala
-Listening for transport dt_socket at address: 8002
-```
-
-* Also see [the Scala README](https://github.com/scala/scala#incremental-compilation) for tips on speeding up compile times.
-* If after introducing changes or updating your clone, you get `AbstractMethodError` or other linkage exceptions, try the `clean` task and building again.
-* Don't underestimate the power of `print`. When starting with Scala, I spent a lot of time in the debugger trying to figure out how
- things work. However later I found out that print-based debugging is often more effective than jumping around. While it might be obvious
- to some, I'd like to explicitly mention that it's also useful to print stack traces to understand the flow of execution. When working with `Trees`, you might want to use `showRaw` to get the `AST` representation.
-* You can publish your newly-built scala version locally using the `publishLocal` task in sbt.
-* It's convenient to enable the following local settings to speed up your workflow (put these in `local.sbt` in your working copy):
-
-```
-// skip docs for local publishing
-publishArtifact in (Compile, packageDoc) in ThisBuild := false
-// set version based on current sha, so that you can easily consume this build from another sbt project
-baseVersionSuffix := s"local-${Process("tools/get-scala-commit-sha").lines.head.substring(0, 7)}"
-// show more logging during a partest run
-testOptions in IntegrationTest in LocalProject("test") ++= Seq(Tests.Argument("--show-log"), Tests.Argument("--show-diff"))
-// if incremental compilation is compiling too much (should be fine under sbt 0.13.13)
-// antStyle := true
-```
-
-* Adding a macro to the `Predef` object is a pretty involved task. Due to bootstrapping, you cannot just throw a macro into it. For this reason, the process is more involved. You might want to follow the way `StringContext.f` itself is added. In short, you need to define your macro under `src/compiler/scala/tools/reflect/` and provide no implementation in `Predef` (`def fn = macro ???`). Now you have to set up the wiring. Add the name of your macro to `src/reflect/scala/reflect/internal/StdNames.scala`, add the needed links to it to `src/reflect/scala/reflect/internal/Definitions.scala`, and finally specify the bindings in `src/compiler/scala/tools/reflect/FastTrack.scala`. [Here's](https://github.com/folone/scala/commit/59536ea833ca16c985339727baed5d70e577b0fe) an example of adding a macro.
-
-### Documentation
-
-There are several areas that one could contribute to -- there is the Scala library, the Scala compiler, and other tools such as Scaladoc. Each area has varying amounts of documentation.
-
-##### The Scala Library
-
-Contributing to the Scala standard library is about the same as working on one of your own libraries. Beyond the Scala collections hierarchy, there are no complex internals or architectures to have to worry about. Just make sure that you code in a "don't-repeat-yourself" (DRY) style, obeying the "boy scout principle" (i.e. make sure you've left the code cleaner than you found it).
-
-If documentation is necessary for some trait/class/object/method/etc in the Scala standard library, typically maintainers will include inline comments describing their design decisions or rationale for implementing things the way they have, if it is not straightforward.
-
-If you intend on contributing to Scala collections, please make sure you're familiar with the design of the Scala collections library. It can be easy to put an implementation in the wrong location if you are unfamiliar with the collections architecture. There is an excellent and very detailed guide covering [the Architecture of Scala Collections](https://docs.scala-lang.org/overviews/core/architecture-of-scala-collections.html), as well as a larger more general [Scala collections Guide](https://docs.scala-lang.org/overviews/collections/introduction.html) covering the sequential portion of collections. For parallel collections, there also exists a detailed [Scala Parallel Collections Guide](https://docs.scala-lang.org/overviews/parallel-collections/overview.html).
-
-##### The Scala Compiler
-
-Documentation about the internal workings of the Scala compiler is scarce, and most of the knowledge is passed around by email ([Scala Contributors](https://contributors.scala-lang.org/) mailing list), ticket, or word of mouth. However the situation is steadily improving. Here are the resources that might help:
-
-* [Compiler internals videos by Martin Odersky](https://www.scala-lang.org/old/node/598.html) are quite dated, but still very useful. In this three-video
- series Martin explains the general architecture of the compiler, and the basics of the front-end, which has recently become Scala reflection API.
-* [Reflection documentation](https://docs.scala-lang.org/overviews/reflection/overview.html) describes fundamental data structures (like `Tree`s, `Symbol`s, and `Types`) that
- are used to represent Scala programs and operations defined on then. Since much of the compiler has been factored out and made accessible via the Reflection API, all of the fundamentals needed for reflection are the same for the compiler.
-* [Reflection and Compilers by Martin Odersky](https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Reflection-and-Compilers), a talk
- at Lang.NEXT 2012 in which Martin elaborates on the design of scalac and the architecture of the reflection API.
-* [Scala compiler corner](https://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/) contains extensive documentation about
- most of the post-typer phases (i.e. the backend) in the Scala compiler.
-* [Scala Contributors](https://contributors.scala-lang.org/), a mailing list which hosts discussions about the core
- internal design and implementation of the Scala system.
-
-##### Other Projects
-
-Tools like Scaladoc also welcome contributions. Unfortunately these smaller projects have less developer documentation. In these cases, the best thing to do is to directly explore the code base (which often contains documentation as inline comments) or to write to the appropriate maintainers for pointers.
-
-### Interlude
-
-To fix [the bug we're interested in](https://github.com/scala/bug/issues/6725) we've tracked the `StringContext.f` interpolator
-down to a macro implemented in `MacroImplementations.scala` There we notice that the interpolator only processes conversions,
-but not tokens like `%n`. Looks like an easy fix.
-
- 18:44 ~/Projects/scala/sandbox (ticket/6725)$ git diff
- diff --git a/src/compiler/scala/tools/reflect/MacroImplementations.scala b/src/compiler/scala/tools/
- index 002a3fce82..4e8f02084d 100644
- --- a/src/compiler/scala/tools/reflect/MacroImplementations.scala
- +++ b/src/compiler/scala/tools/reflect/MacroImplementations.scala
- @@ -117,7 +117,8 @@ abstract class MacroImplementations {
- if (!strIsEmpty) {
- val len = str.length
- while (idx < len) {
- - if (str(idx) == '%') {
- + def notPercentN = str(idx) != '%' || (idx + 1 < len && str(idx + 1) != 'n')
- + if (str(idx) == '%' && notPercentN) {
- bldr append (str substring (start, idx)) append "%%"
- start = idx + 1
- }
-
-After applying the fix and running `sbt compile`, our simple test case in `sandbox/Test.scala` started working!
-
- 18:51 ~/Projects/scala/sandbox (ticket/6725)$ cd ..
- 18:51 ~/Projects/scala (ticket/6725)$ sbt compile
- ...
- [success] Total time: 18 s, completed Jun 6, 2016 9:03:02 PM
- Total time: 18 seconds
-
- 18:51 ~/Projects/scala (ticket/6725)$ cd sandbox
- 18:51 ~/Projects/scala/sandbox (ticket/6725)$ ../build/pack/bin/scalac Test.scala
- 18:51 ~/Projects/scala/sandbox (ticket/6725)$ ../build/pack/bin/scala Test
- 1
- 1 // no longer getting the %n here - it got transformed into a newline
-
-### Test
-
-To guard your change against accidental breakage in the future, it is important to add tests.
-I have already written one test earlier, so that's a good start but not enough! Apart from obvious usages of our new functionality, we need to cover corner-cases as well.
-
-Adding tests to the test suite is as easy as moving them to the appropriate directory:
-
-* Code which should compile successfully, but doesn't need to be executed, needs to go into the [“pos” directory](https://github.com/scala/scala/tree/2.12.x/test/files/pos).
-* Code which should not compile needs to go into the [“neg” directory](https://github.com/scala/scala/tree/2.12.x/test/files/neg).
-* Code which should compile and get executed by the test suite needs to go into the [“run” directory](https://github.com/scala/scala/tree/2.12.x/test/files/run) and have a corresponding `.check` file with the expected output. You will get test failures if the content of a `.check` file is different from what the test produces while running. If the change in the output is an expected product of your work, you might not want to change the `.check` file by hand. To make partest change the `.check` file, run it with a `--update-check` flag, like so `./test/partest --update-check path/to/test.scala`. For more information on partest, please refer to its [documentation](https://docs.scala-lang.org/tutorials/partest-guide.html).
-* Everything that can be unit-tested should go to ["junit" directory](https://github.com/scala/scala/tree/2.12.x/test/junit)
-* Property-based tests go to the ["scalacheck" directory](https://github.com/scala/scala/tree/2.12.x/test/scalacheck)
-
-Here are some more testing tips:
-
-* If you have several tests, and want a tool for only running tests that conform to some regular expression, you can use `partest-ack` in the `tools` directory: `./tools/partest-ack "dottype"`. `partest-ack` was removed in 2.12.
-* If you want to run all scalacheck tests from sbt use `scalacheck/testOnly`
-* To run scalacheck tests by name when in sbt use `scalacheck/testOnly 
-
-### Review
-
-After the pull request has been submitted, you need to pick a reviewer (usually the person you've contacted in the beginning of your
-workflow) and be ready to elaborate and adjust your patch if necessary. In this example, we picked Martin, because we had such a nice chat on the mailing list:
-
-
-
-## Merge
-
-After your reviewer is happy with your code (usually signaled by a LGTM — “Looks good to me”), your job is done.
-Note that there can be a gap between a successful review and the merge, because not every reviewer has merge rights. In that case, someone else from the team will pick up your pull request and merge it.
-So don't be confused if your reviewer says “LGTM”, but your code doesn't get merged immediately.
diff --git a/contribute/inclusive-language-guide.md b/contribute/inclusive-language-guide.md
index 670353259..5ff5e78b5 100644
--- a/contribute/inclusive-language-guide.md
+++ b/contribute/inclusive-language-guide.md
@@ -1,132 +1,6 @@
---
title: Inclusive Language Guide
-layout: inner-page-no-masthead
-includeTOC: true
permalink: /contribute/inclusive-language/
+redirect_to:
+ - https://docs.scala-lang.org/contribute/inclusive-language-guide.html
---
-
-We are committed to providing a friendly, safe and welcoming environment for
-all, regardless of age, body size, disability, ethnicity, sex characteristics,
-gender identity and expression, level of experience, education, socio-economic
-status, nationality, personal appearance, race, religion, sexual identity
-and orientation, or other such characteristics.
-
-Language is a powerful vehicle of ideas and representations, and as such, can highlight, accentuate, or blur certain characteristics of the world.
-Language -- in its use and structure -- may bias our perception of the world, sometimes to the disadvantage of some people.
-Different language strategies have therefore been suggested to promote more inclusive forms of language, echoing the need for more equal treatment for all.
-
-This inclusive language guide is therefore intended to help us adopt a more inclusive way of communicating.
-Although the present guide does not exhaustively cover all issues pertaining to non-inclusive language, it covers the most important issues we are currently aware of.
-
-Contributions made to the core Scala projects and their documentation -- including to this website -- should follow this guide.
-
-## Non gendered language
-
-The use of *He*, *Him*, *His*, *Man* and *Men* should be avoided.
-Although these terms are intended to refer to any genders (male, female, other, unknown or irrelevant), they imply that the subject is male and therefore excludes all other genders.
-Instead, use the singular *they*, as already used by famous authors like Jane Austen.
-
-Example of the use of singular they:
-
-> When a developer wants to contribute to a project, they open a pull request.
-
-Although *they* refers to a single person, we conjugate the verb with the plural form.
-This is similar to the polite form of pronouns in certain languages, such as "Sie" in German or "vous" in French.
-
-When possible, avoid (combined) words that refer to a specific gender, and use gender-neutral alternatives instead.
-For example:
-
-* *man* or *woman* -> *person*
-* *chairman* -> *chairperson*
-
-## The words easy, simple, quick, and trivial
-
-What might be easy for you might not be easy for others.
-The same applies to other words like *quick* or *simple*.
-When used in the positive or superlative forms, try eliminating this word from sentences because usually the same meaning can be conveyed without it.
-
-Example of a positive form:
-
-> You can then simply execute the program with the `run` command.
-
-can be replaced with
-
-> You can then execute the program with the `run` command.
-
-without changing the meaning of the sentence.
-
-Example of a superlative form:
-
-> The foobar method is the easiest way to get started with our library.
-
-can be replaced with
-
-> We show here how to use the foobar method to get started with our library.
-
-However, the comparative form of these adjectives and adverbs can be used when relevant.
-
-Example of a comparative form:
-
-> The foobar method is quicker to get started with than the baz method.
-
-Similarly, the word *just* is usually redundant and can be removed without altering the meaning.
-
-Example:
-
-> You can just add these settings to your build.
-
-can be replaced with
-
-> You can add these settings to your build.
-
-Of course, every situation is different, and there may be cases where using "the easy words" is still the best thing to do.
-In that case, it should be a deliberate decision to use them, taking the above considerations into account.
-
-## Specific loaded words
-
-Some words may have a derogatory connotation and/or have clear oppressive origins.
-Avoid these words to the greatest extent possible, and use neutral alternatives instead.
-Currently, the following words, used for common computer science concepts, are discouraged.
-This list is neither comprehensive nor definitive, and it can evolve over time.
-
-* **blacklist/whitelist** \
- While the etymology of these words has no relation to racism, their use suggests an association between the color black and some form of badness or exclusion, and between the color white and some form of goodness or inclusion.
- Prefer alternatives when possible.
- Several alternatives have been proposed but none sticks as "the one". We suggest using the pair *excludelist*/*includelist*, as it is generic enough to replace all uses of *blacklist*/*whitelist*.
-* **master/slave** \
- Never use *slave*.
- Never use *master* in conjunction with *slave*.
- Depending on the specific architecture, use one of the following alternatives instead: *controller*/*worker*, *primary*/*secondary*, *leader*/*follower*, etc.
- When in doubt, if you cannot choose, *primary*/*secondary* is always a decent fallback. \
- When used with the meaning of *teacher*, *expert*, *guide*, or *reference*, the word *master* is not specifically discouraged.
- For example, the term *Master of the arts* is acceptable. \
- Note: there exists a broader movement of using `main` instead of `master` as the default git branch, led by GitHub and the git project themselves, and which we encourage people to follow as well.
-* **sanity check** \
- Prefer *confidence check*.
-* **segregated** \
- Computer science concepts like the *interface segregation principle* and *segregated networks* present segregation as being desirable, instead of bad.
- Prefer alternatives like *separation of concerns* and *segmented networks*.
-* **guru** \
- While a *guru* initially refers to a respected spiritual leader, it also designates the chief of a sect.
- Both are of a spiritual nature and are ambiguous.
- If possible, use a more precise term such as *teacher* or *expert*.
-
-A good source with explainers and references can be found at [https://github.com/dialpad/inclusive-language](https://github.com/dialpad/inclusive-language).
-
-Keep in mind that your particular application domain may contain its own share of domain-specific loaded words.
-We encourage you to research inclusive language guidelines applicable to your domain.
-
-You may want to use automated software like [In Solidarity](https://github.com/apps/in-solidarity) to steer contributors away from loaded words.
-
-## Backward compatibility
-
-Sometimes, we have existing code, APIs or commands that do not follow the above recommendations.
-It is generally advisable to perform renamings to address the issue, but that should not be done to the detriment of backward compatibility (in particular, backward binary compatibility of libraries).
-Deprecated aliases should be retained when possible.
-
-Sometimes, it is not possible to preserve backward compatibility through renaming; for example for methods intended to be overridden by user-defined subclasses.
-In those cases, we recommend to keep the old names, but document (e.g., in Scaladoc comments) that they are named as they are for historical reasons and to preserve compatibility, and what their intended name should be.
-
-## See also
-
-* Our [code of conduct](../../conduct/).
diff --git a/contribute/index.md b/contribute/index.md
index d78a72e15..c26b3bead 100644
--- a/contribute/index.md
+++ b/contribute/index.md
@@ -1,67 +1,6 @@
---
title: Contribute
-layout: inner-page-no-masthead
# permalink: /contribute/
-includeTOC: true
+redirect_to:
+ - https://docs.scala-lang.org/contribute/index.html
---
-
-The Scala programming language is an open source project with a very
-diverse community, where people from all over the world contribute their work,
-with everyone benefiting from friendly help and advice, and
-kindly helping others in return. So why not join the Scala community and help
-everyone make things better?
-
-## How to help?
-
-That depends on what you want to contribute. Below are some getting started resources for different contribution domains. Please read all of the documentation and follow all the links from the topic pages below before attempting to contribute, as many of the questions you have will already be answered.
-
-### Reporting bugs
-
-See our [bug reporting guide](/contribute/bug-reporting-guide.html) to learn
-how to efficiently report a bug.
-
-### Contribute
-
-Coordination of contribution efforts takes place on
-[Scala Contributors](https://contributors.scala-lang.org/).
-
-{% include column-list-of-items.html collection=site.contribute_resources %}
-
-### Guidelines
-
-When contributing, please follow:
-
-* The [Scala Code of Conduct](../conduct/)
-* The [Inclusive Language Guide](./inclusive-language/)
-
-### Community Tickets
-
-All issues can be found in the [Scala bug tracker](https://github.com/scala/bug). Most issues are labeled
-to make it easier to find issues you are interested in.
-
-### Tools and Libraries
-
-The Scala ecosystem includes a great many diverse open-source projects
-with their own maintainers and community of contributors. Helping out
-one of these projects is another way to help Scala. Consider lending
-on a hand on a project you're already using. Or, to find out about
-other projects, see the
-[Libraries and Tools section](/community/#community-libraries-and-tools)
-on our Community page.
-
-### Scala Community Build
-
-The Scala community build enables the Scala compiler team
-to build and test a corpus of
-Scala open source projects
-against development versions of the Scala compiler and standard
-library in order to discover regressions prior to releases.
-The build uses Lightbend's
-[dbuild](https://github.com/typesafehub/dbuild) tool,
-which leverages [sbt](https://www.scala-sbt.org).
-
-If you're the maintainer -- or just an interested user! -- of an
-open-source Scala library or tool, please visit the
-[community build documentation](https://github.com/scala/community-build/wiki)
-for guidelines on what projects are suitable for the community build
-and how projects can be added.
diff --git a/contribute/partest-guide.md b/contribute/partest-guide.md
index e7e10621e..6b0ed0ce6 100644
--- a/contribute/partest-guide.md
+++ b/contribute/partest-guide.md
@@ -1,88 +1,6 @@
---
title: Running the Test Suite
-layout: inner-page-no-masthead
# permalink: /contribute/partest-guide/
-includeTOC: true
+redirect_to:
+ - https://docs.scala-lang.org/contribute/partest-guide.html
---
-
-Partest is a custom parallel testing tool that we use to run the test suite for the Scala compiler and library. Go to the scala project folder from your local checkout and run it via `sbt`, `ant` or standalone as follows.
-
-## Using sbt
-
-The test suite can be run from the sbt console with:
-
- > partest
-
-You can get a summary of the usage by running `partest --help`.
-
-If you would like to run particular tests pass the test paths as arguments
-
- > partest test/files/pos/bounds.scala test/scaladoc/run/diagrams-base.scala
-
-To run only the Scaladoc tests use `--srcpath` with the location of the tests
-
- > partest --srcpath scaladoc
-
-## Using ant
-
-Please note support for ant was removed on the 2.12 branch.
-
-The test suite can be run by using ant from the command line:
-
- $ ant test.suite
-
-## Standalone
-
-Please note the standalone scripts mentioned below were removed in 2.12.2. sbt is the preferred way to run the test suite.
-
-There are launch scripts `partest` and `partest.bat` in the `test` folder of the scala project. To have partest run failing tests only and print details about test failures to the console, you can use
-
- ./test/partest --show-diff --show-log --failed
-
-You can get a summary of the usage by running partest without arguments.
-
-* Most commonly you want to invoke partest with an option that tells it which part of the tests to run. For example `--all`, `--pos`, `--neg` or `--run`.
-* You can test individual files by specifying individual test files (`.scala` files) as options. Several files can be tested if they are from the same category, e.g., `pos`.
-* You can enable output of log and diff using the `-show-log` and `-show-diff` options.
-* If you get into real trouble, and want to find out what partest does, you can run it with option `--verbose`. This info is useful as part of bug reports.
-* Set custom path from where to load classes: `-classpath