Merge pull request swiftlang#3023 from dnicolson/update-contributing-…

…docs

Update contributing docs

CONTRIBUTING.md

@@ -15,7 +15,7 @@ Please remember to include platform information with your report. If the bug is
 
 ## Pull Requests
 
-Before embarking on a large amount of work to implement missing functionality, please double-check with the community on the [swift-corelibs-dev](https://lists.swift.org/mailman/listinfo/swift-corelibs-dev) mailing list. Someone may already be working in this area, and we want to avoid duplication of work.
+Before embarking on a large amount of work to implement missing functionality, please double-check with the community in the [Swift Forums](https://forums.swift.org/). Someone may already be working in this area, and we want to avoid duplication of work.
 
 If your request includes functionality changes, please be sure to test your code on Linux as well as macOS. Differences in the compiler and runtime on each platform means that code that compiles and runs correctly on Darwin (where the Objective-C runtime is present) may not compile at all on Linux.
 

Docs/Testing.md

@@ -148,7 +148,7 @@ Unlike XFAIL tests in `lit.py`, tests that are expected to fail will _not_ execu
 
 ### Why and How
 
-In general, we want to ensure that tests are written to check the _contract_ of the API, [as documented for each class](https://developer.apple.com/). It is of course acceptable to have the test implementation be informed by the implementation, but we want to make sure that tests still make sense if we replace an implementation entirely, [as we sometimes do](https://github.com/apple/swift-corelibs-foundation/pull/2331).
+In general, we want to ensure that tests are written to check the _contract_ of the API, [as documented for each class](https://developer.apple.com/). It is of course acceptable to have the test implementation be informed by the implementation, but we want to make sure that tests still make sense if we replace an implementation entirely, [as we sometimes do](https://github.com/apple/swift-corelibs-foundation/pull/2331).
 
 This doesn't always work. Sometimes the contract specifies that a certain _result_ will occur, and that result may be platform-specific or trigger in multiple ways, all of which we'd like to test (for example, different file operation paths for volumes with different capabilities). In this case, we can reach into Foundation's `internal` methods by using `@testable import` and test the component parts or invoke private API ("SPI") to alter the behavior so that all paths are taken.