Respond to @stephentoub feedback on bad links

dotnet · Jun 1, 2015 · 18c39ac · 18c39ac
1 parent 550d51d
commit 18c39ac
Show file tree

Hide file tree

Showing 14 changed files with 38 additions and 19 deletions.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -3,9 +3,9 @@
 See [Contributing] on the wiki for information about coding styles, source structure, making
 pull requests, and more.
 
-[Contributing]: https://github.com/dotnet/corefx/wiki/Contributing
+[Contributing]: https://github.com/dotnet/corefx/blob/master/Documentation/contributing-corefx.md
 # Developers
 
 See the [Developer Guide] for details about developing in this repo.
 
-[Developer Guide]: https://github.com/dotnet/corefx/wiki/Developer-Guide
+[Developer Guide]: https://github.com/dotnet/corefx/blob/master/Documentation/developer-guide.md
diff --git a/Documentation/README.md b/Documentation/README.md
@@ -18,6 +18,7 @@ Get .NET Core
 Project Docs
 ============
 
+- [Developer Guide](developer-guide.md)
 - [Project priorities](https://github.com/dotnet/coreclr/blob/master/Documentation/project-priorities.md)
 - [Contributing to .NET Core](https://github.com/dotnet/coreclr/blob/master/Documentation/contributing.md)
 - [Contributing Workflow](https://github.com/dotnet/coreclr/blob/master/Documentation/contributing-workflow.md)

diff --git a/Documentation/api-review-process.md b/Documentation/api-review-process.md
@@ -33,7 +33,7 @@ For work that involves adding new APIs we'd like the issue to contain what we ca
 
 * **Coding**. The contributor is implementing the APIs as discussed. Minor deviations are OK, but if during the implementation the design starts to take a major shift, the contributor is encouraged to go back to the issue and raise the concerns with the current proposal.
 
-* **Pull request is being created**. Once the contributor believes the implementation is ready for review, she creates a pull request, referencing the issue created in the first step. In order to call dips, you can also create the PR before it's completely ready. Use checkboxes to indicate which areas are still missing so that we know it's not ready for review yet. [Here is a good example](https://github.com/dotnet/corefx/pull/316). At this time, if any new API are being added to a type that has shipped in the full .NET Framework, submit the pull request to the *future* branch. See [[Branching Guide]].
+* **Pull request is being created**. Once the contributor believes the implementation is ready for review, she creates a pull request, referencing the issue created in the first step. In order to call dips, you can also create the PR before it's completely ready. Use checkboxes to indicate which areas are still missing so that we know it's not ready for review yet. [Here is a good example](https://github.com/dotnet/corefx/pull/316). At this time, if any new API are being added to a type that has shipped in the full .NET Framework, submit the pull request to the *future* branch. See [Branching Guide](branching-guide.md).
 
 * **Pull request is being reviewed**. The community reviews the code for the pull request. The review should focus on the code changes and architecture - not the APIs themselves. Once at least two project owners give their OK, the PR is considered good to go.
 

diff --git a/Documentation/contributing-corefx.md b/Documentation/contributing-corefx.md
@@ -6,12 +6,12 @@ This document describes contribution guidelines that are specific to CoreFX. Ple
 Coding Style Changes
 --------------------
 
-We intend to bring dotnet/corefx in to full conformance with the style guidelines described in [Coding Style](https://github.com/dotnet/corefx/blob/master/Documentation/coding-style.md). We plan to do that with tooling, in a holistic way. In the meantime, please:
+We intend to bring dotnet/corefx in to full conformance with the style guidelines described in [Coding Style](coding-style.md). We plan to do that with tooling, in a holistic way. In the meantime, please:
 
 * **DO NOT** send PRs for style changes. 
 * **DO** give priority to the current style of the project or file you're changing even if it diverges from the general guidelines.
 
 API Changes
 -----------
 
-* **DON'T** submit API additions to any type that has shipped in the full .NET framework to the *master* branch. Instead, use the *future* branch. See [[Branching Guide]].
+* **DON'T** submit API additions to any type that has shipped in the full .NET framework to the *master* branch. Instead, use the *future* branch. See [Branching Guide](branching-guide.md).
diff --git a/Documentation/developer-guide.md b/Documentation/developer-guide.md
@@ -0,0 +1,18 @@
+Developer Guide
+===============
+
+This guide provides instructions (mostly as links) on how to build the repo and implement improvements. It will expand over time.
+
+Building the repository
+=======================
+
+The CoreFX repo can be built from a regular, non-admin command prompt. The build produces multiple managed binaries that make up the CoreFX libraries and the accompanying tests. The repo can be built for the following platforms, using the provided instructions.
+
+| Chip  | Windows | Linux | OS X |
+| :---- | :-----: | :---: | :--: |
+| x64   | &#x25CF;| &#x25D2;| &#x25D2; |		  
+| x86   | &#x25EF;| &#x25EF;| &#x25EF;|
+| ARM32 | &#x25EF; | &#x25EF;| &#x25EF; |
+|       | [Instructions](windows-instructions.md) | [Instructions](linux-instructions.md) | |  
+
+The CoreFX build and test suite is a work in progress, as are the [building and testing instructions](README.md). The .NET Core team and the community are improving Linux and OS X support on a daily basis are and adding more tests for all platforms. See [CoreFX Issues](https://github.com/dotnet/corefx/issues) to find out about specific work items or report issues.
diff --git a/Documentation/linux-instructions.md b/Documentation/linux-instructions.md
@@ -1,7 +1,7 @@
 Building CoreFX on Linux
 ========================
 
-CoreFx can be built on top of current [Mono CI builds](https://github.com/dotnet/corefx/wiki/Building-On-Unix#installing-mono-packages) or a direct [build/install of Mono](http://www.mono-project.com/docs/compiling-mono/). It builds using MSBuild and Roslyn and requires changes that have not yet made it to official released builds.
+CoreFx can be built on top of current [Mono CI builds](#installing-mono-packages) or a direct [build/install of Mono](http://www.mono-project.com/docs/compiling-mono/). It builds using MSBuild and Roslyn and requires changes that have not yet made it to official released builds.
 
 After preparing Mono, clone if you haven't already, and run the build script.
 

diff --git a/Documentation/oss-signing.md b/Documentation/oss-signing.md
@@ -1,7 +1,7 @@
 Open Source Signing
 ===================
 
-For reasons listed over on [Strong Naming](Strong Naming), all .NET Core assemblies are strong-named.
+For reasons listed over on [Strong Naming](strong-name-signing.md), all .NET Core assemblies are strong-named.
 
 To enable you to build assemblies that have a matching identity to what Microsoft would build, we leverage a new signing mechanism called _Open Source Signing (OSS)_. This lets you clone the dotnet/corefx repository, build and then drop the resulting assembly in your application with zero changes to consuming libraries. By default, all .NET Core projects build using OSS.
 

diff --git a/Documentation/performance-guidelines.md b/Documentation/performance-guidelines.md
@@ -5,11 +5,11 @@ Different applications have different needs when it comes to performance.  For l
 
 Much has been written about writing high-performance code in C#.  This page provides links to some of that material and will expand over time as additional resources are found and identified as being relevant and useful.
 
-CoreCLR performance guidelines are available [here](https://github.com/dotnet/coreclr/wiki/Performance).
+You can read [CoreCLR Performance Requirements](https://github.com/master/coreclr/blob/master/Documentation/performance-requirements.md) to learn more.
 
 # Memory Management
 
-* **Avoiding delegate and closure allocations for lambdas**.  The code generated by the C# compiler for anonymous methods and lambdas may involve one or more allocations.  Certain patterns in APIs can help to avoid these allocations.  See this [blog post](http://blogs.msdn.com/b/pfxteam/archive/2012/02/03/10263921.aspx) for more information.
+* **Avoiding delegate and closure allocations for lambdas**.  The code generated by the C# compiler for anonymous methods and lambdas may involve one or more allocations.  Certain patterns in APIs can help to avoid these allocations.  See [Know Thine Implicit Allocations](http://blogs.msdn.com/b/pfxteam/archive/2012/02/03/10263921.aspx) for more information.
 
 # Asynchrony
 

diff --git a/Documentation/repo-organization.md b/Documentation/repo-organization.md
@@ -29,4 +29,4 @@ tests\
     test_folder_2\
         test_1.cs
         test_2.cs
-```
+```
diff --git a/Documentation/strong-name-signing.md b/Documentation/strong-name-signing.md
@@ -21,4 +21,4 @@ There are three major problems that developers run into after strong naming thei
 
 2. _Virality_. Once you've strong-named an assembly, you can only statically reference other strong-named assemblies. 
 
-3. _No drop-in replacement_. This is a problem for open source libraries where the strong-name private key is not checked into the repository. This means that developers are unable to build to their own version of the library and then use it as a drop-in replacement without recompiling _all_ consuming libraries up stack to pick up the new identity. This is extremely problematic for libraries, such as Json.NET, which have large incoming dependencies. Firstly, we would recommend that these open source projects check-in their private key (remember, [strong-names are used for identity, and not for security](http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx)). Failing that, however, we've introduced a new concept called [[Open Source Signing]] that enables developers to build drop-in replacements without needing access to the strong-name private key. This is the mechanism that .NET Core libraries use by default.
+3. _No drop-in replacement_. This is a problem for open source libraries where the strong-name private key is not checked into the repository. This means that developers are unable to build to their own version of the library and then use it as a drop-in replacement without recompiling _all_ consuming libraries up stack to pick up the new identity. This is extremely problematic for libraries, such as Json.NET, which have large incoming dependencies. Firstly, we would recommend that these open source projects check-in their private key (remember, [strong-names are used for identity, and not for security](http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx)). Failing that, however, we've introduced a new concept called [Open Source Signing](oss-signing.md) that enables developers to build drop-in replacements without needing access to the strong-name private key. This is the mechanism that .NET Core libraries use by default.
diff --git a/Documentation/windows-instructions.md b/Documentation/windows-instructions.md
@@ -21,7 +21,7 @@ the core tests for the project. Visual Studio Solution (.sln) files exist for
 related groups of libraries. These can be loaded to build, debug and test inside
 the Visual Studio IDE.
 
-[[Building On Unix]]
+[Building On Linux](linux-instructions.md)
 ## Tests
 
 We use the OSS testing framework [xunit](http://xunit.github.io/)

diff --git a/README.md b/README.md
@@ -28,9 +28,9 @@ Want to get more familiar with what's going on in the code?
 
 Looking for something to work on? The list of [up-for-grabs issues](https://github.com/dotnet/corefx/labels/up%20for%20grabs) is a great place to start or for larger items see the list of [feature approved](https://github.com/dotnet/corefx/labels/feature%20approved). See some of our guides for more details:
 
-* [Contributing Guide](https://github.com/dotnet/corefx/wiki/Contributing)
-* [Developer Guide](https://github.com/dotnet/corefx/wiki/Developer-Guide)
-* [Issue Guide](https://github.com/dotnet/corefx/wiki/Issue-Guide)
+* [Contributing Guide](Documentation/contributing-corefx.md)
+* [Developer Guide](developer-guide.md)
+* [Issue Guide](issue-guide.md)
 
 You are also encouraged to start a discussion by filing an issue or creating a
 gist.

diff --git a/build.cmd b/build.cmd
@@ -18,7 +18,7 @@ if not defined VisualStudioVersion (
     )
 
     echo Error: build.cmd requires Visual Studio 2013 or 2015.  
-    echo        Please see https://github.com/dotnet/corefx/wiki/Developer-Guide for build instructions.
+    echo        Please see https://github.com/dotnet/corefx/blob/master/Documentation/developer-guide.md for build instructions.
     exit /b 1
 )
 

diff --git a/build.sh b/build.sh
@@ -21,12 +21,12 @@ __referenceassemblyroot=$__monoroot/lib/mono/xbuild-frameworks
 __monoversion=$(mono --version | grep "version 4.[1-9]")
 
 if [ $? -ne 0 ]; then
-    echo "Mono 4.1 or later is required to build corefx. Please see https://github.com/dotnet/corefx/wiki/Building-On-Unix for more details."
+    echo "Mono 4.1 or later is required to build corefx. Please see https://github.com/dotnet/corefx/blob/master/Documentation/linux-instructions.md for more details."
     exit 1
 fi
 
 if [ ! -e "$__referenceassemblyroot/.NETPortable" ]; then
-    echo "PCL reference assemblies not found. Please see https://github.com/dotnet/corefx/wiki/Building-On-Unix for more details."
+    echo "PCL reference assemblies not found. Please see https://github.com/dotnet/corefx/blob/master/Documentation/linux-instructions.md for more details."
     exit 1
 fi
 
@@ -37,7 +37,7 @@ __buildlog=$__scriptpath/msbuild.log
 if [ ! -e "$__nugetpath" ]; then
     which curl wget > /dev/null 2> /dev/null
     if [ $? -ne 0 -a $? -ne 1 ]; then
-        echo "cURL or wget is required to build corefx. Please see https://github.com/dotnet/corefx/wiki/Building-On-Unix for more details."
+        echo "cURL or wget is required to build corefx. Please see https://github.com/dotnet/corefx/blob/master/Documentation/linux-instructions.md for more details."
         exit 1
     fi
     echo "Restoring NuGet.exe..."