+
+
+ ```scala mdoc
+val a = 1
+```
```scala mdoc:fail
+val b: String = 3
+```
```scala mdoc
+import java.time.Instant
+
+def now() = Instant.now()
+object Foo {}
+```
```scala mdoc:nest
+case class Foo(a: Int)
+```
```scala mdoc
+val a = s"The time is ${now()}"
+```
```scala mdoc:reset
+case class Foo(a: String)
+```
```scala mdoc
+val myFoo = Foo("hi")
+```
+
+
+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
+[scala/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 JDK. The baseline version is `8` for 2.13.x and higher. It's possible to use a higher JDK version 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.
+
+macOS and Linux builds should work. Windows is supported, but it might have issues. Please report to the [Scala 2 bug tracker](https://github.com/scala/bug) if you encounter any.
+
+Building Scala can be done with a single command `sbt dist/mkPack`, from 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.
+
+IntelliJ IDEA has a Scala plugin, which is known to work with our codebase. Alternatively you can use Visual Studio Code with the [Metals IDE extension](https://marketplace.visualstudio.com/items?itemName=scalameta.metals).
+Both of these Scala IDE solutions provide navigation, refactoring, error reporting functionality, and integrated debugging.
+See [the Scala README](https://github.com/scala/scala#ide-setup) for instructions on using either IntelliJ IDEA or Metals with the Scala repository.
+
+Other alternative editors exist, such as Atom, Emacs, Sublime Text or jEdit. These are faster and much less memory/compute-intensive to run, but lack semantic services and debugging.
+
+We recognise that there exist preferences towards specific IDE/editor experiences, so ultimately we recommend that your choice be your personal preference.
+
+## 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 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 using `println` to print debug information. 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. It's also useful to print stack traces to understand the flow of execution, for example what code executed before some action occurred. 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, it makes it more complex to add a macro. For this reason, the process is more involved. It could be useful to replicate 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` (it will look like `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.
+
+### Where to Find Documentation
+
+The separate projects under Scala have 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.
+
+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.
+
+The Scala collections framework, part of the Scala standard library, is more complex. You should become familiar
+with its architecture, which is documented in [the Architecture of Scala Collections][collections-arch].
+The [Scala Collections Guide][collections-intro] is more general, covering the synchronous portion of collections. For parallel collections, there also exists a detailed [Scala Parallel Collections Guide][collections-par].
+
+##### The Scala Compiler
+
+Documentation about the internal workings of the Scala compiler is scarce, and most of the knowledge is passed around by forum ([Scala Contributors](https://contributors.scala-lang.org/) forum), chat-rooms (see `#scala-contributors` on [Discord][discord-contrib]), 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 later became the `scala-reflect` module's API.
+* [Reflection documentation][reflect-overview] 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 `scala-reflect` module, all of the fundamentals needed for reflection are the same for the compiler.
+* [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 forum 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://github.com/scala/scala-partest).
+* 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.
+
+[collections-arch]: {% link _overviews/core/architecture-of-scala-collections.md %}
+[collections-intro]: {% link _overviews/collections-2.13/introduction.md %}
+[collections-par]: {% link _overviews/parallel-collections/overview.md %}
+[reflect-overview]: {% link _overviews/reflection/overview.md %}
+[partest-guide]: {% link _overviews/contribute/partest-guide.md %}
+[documentation]: {% link _overviews/contribute/documentation.md %}
+[contrib-forum]: https://contributors.scala-lang.org/
+[discord-contrib]: https://discord.com/invite/scala
diff --git a/_overviews/contribute/inclusive-language-guide.md b/_overviews/contribute/inclusive-language-guide.md
new file mode 100644
index 0000000000..375d988158
--- /dev/null
+++ b/_overviews/contribute/inclusive-language-guide.md
@@ -0,0 +1,130 @@
+---
+title: Inclusive Language Guide
+num: 2
+---
+
+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](https://scala-lang.org/conduct/).
diff --git a/_overviews/contribute/index.md b/_overviews/contribute/index.md
new file mode 100644
index 0000000000..da197e233e
--- /dev/null
+++ b/_overviews/contribute/index.md
@@ -0,0 +1,68 @@
+---
+title: Introduction
+num: 1
+---
+
+### Why You Should Contribute To Scala
+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?
+
+**What Can I Do?**
+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][bug-reporting-guide] 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](https://scala-lang.org/conduct/)
+* The [Inclusive Language Guide][inclusive-language-guide]
+
+### Community Tickets
+
+All issues can be found in the [Scala bug tracker](https://github.com/scala/bug), or the [Scala 3 issue tracker](https://github.com/lampepfl/dotty/issues). 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](https://scala-lang.org/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.
+
+[bug-reporting-guide]: {% link _overviews/contribute/bug-reporting-guide.md %}
+[inclusive-language-guide]: {% link _overviews/contribute/inclusive-language-guide.md %}
diff --git a/_overviews/contribute/partest-guide.md b/_overviews/contribute/partest-guide.md
new file mode 100644
index 0000000000..c8eb5cbf02
--- /dev/null
+++ b/_overviews/contribute/partest-guide.md
@@ -0,0 +1,92 @@
+---
+title: Running the Test Suite
+num: 13
+---
+
+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:
+
+```
+sbt:root> 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
+
+```
+sbt:root> 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
+
+```
+sbt:root> 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