45 files changed, 128 insertions, 128 deletions
diff --git a/Documentation/README.md b/Documentation/README.md
index 93b618668e..5cd69e7f82 100644
--- a/Documentation/README.md
+++ b/Documentation/README.md
@@ -12,71 +12,71 @@ Learn about .NET Core
 Get .NET Core
 =============
 
-- [Get .NET Core DNX SDK on Windows](get-dotnetcore-dnx-windows.md)
-- [Get .NET Core DNX SDK on OS X](get-dotnetcore-dnx-osx.md)
-- [Get .NET Core DNX SDK on Linux](get-dotnetcore-dnx-linux.md)
-- [Get .NET Core (Raw) on Windows](get-dotnetcore-windows.md)
+- [Get .NET Core DNX SDK on Windows](installing/get-dotnetcore-dnx-windows.md)
+- [Get .NET Core DNX SDK on OS X](installing/get-dotnetcore-dnx-osx.md)
+- [Get .NET Core DNX SDK on Linux](installing/get-dotnetcore-dnx-linux.md)
+- [Get .NET Core (Raw) on Windows](installing/get-dotnetcore-windows.md)
 
 Project Docs
 ============
 
-- [Developer Guide](developer-guide.md)
-- [Project priorities](project-priorities.md)
-- [Contributing to .NET Core](contributing.md)
-- [Contributing Workflow](contributing-workflow.md)
-- [Performance Guidelines](performance-guidelines.md)
-- [Garbage Collector Guidelines](garbage-collector-guidelines.md)
+- [Developer Guide](project-docs/developer-guide.md)
+- [Project priorities](project-docs/project-priorities.md)
+- [Contributing to .NET Core](project-docs/contributing.md)
+- [Contributing Workflow](project-docs/contributing-workflow.md)
+- [Performance Guidelines](project-docs/performance-guidelines.md)
+- [Garbage Collector Guidelines](project-docs/garbage-collector-guidelines.md)
 
 Coding Guidelines
 =================
 
-- [CLR Coding Guide](clr-code-guide.md)
-- [CLR JIT Coding Conventions](clr-jit-coding-conventions.md)
-- [Cross Platform Performance and Eventing Design](cross-platform-performance-and-eventing.md)
+- [CLR Coding Guide](coding-guidelines/clr-code-guide.md)
+- [CLR JIT Coding Conventions](coding-guidelines/clr-jit-coding-conventions.md)
+- [Cross Platform Performance and Eventing Design](coding-guidelines/cross-platform-performance-and-eventing.md)
 
 Build CoreCLR from Source
 =========================
 
-- [Building CoreCLR on FreeBSD](freebsd-instructions.md)
-- [Building CoreCLR on Linux](linux-instructions.md)
-- [Building CoreCLR on OS X](osx-instructions.md)
-- [Building CoreCLR on Windows](windows-instructions.md)
-- [Debugging CoreCLR on Windows](windows-debugging-instructions.md)
-- [Testing Changes on Windows](windows-test-instructions.md)
-- [Testing with CoreFX](testing-with-corefx.md)
-- [Creating a Custom DNX](custom-dnx-instructions.md)
+- [Building CoreCLR on FreeBSD](building/freebsd-instructions.md)
+- [Building CoreCLR on Linux](building/linux-instructions.md)
+- [Building CoreCLR on OS X](building/osx-instructions.md)
+- [Building CoreCLR on Windows](building/windows-instructions.md)
+- [Debugging CoreCLR on Windows](building/windows-debugging-instructions.md)
+- [Testing Changes on Windows](building/windows-test-instructions.md)
+- [Testing with CoreFX](building/testing-with-corefx.md)
+- [Creating a Custom DNX](building/custom-dnx-instructions.md)
 
 Book of the Runtime
 ===================
 
-- [Book of the Runtime FAQ](botr-faq.md)
-- [Introduction to the Common Language Runtime](intro-to-clr.md)
-- [Garbage Collection Design](garbage-collection.md)
-- [Threading](threading.md)
-- [RyuJIT Overview](ryujit-overview.md)
-- [Type System](type-system.md)
-- [Type Loader](type-loader.md)
-- [Method Descriptor](method-descriptor.md)
-- [Virtual Stub Dispatch](virtual-stub-dispatch.md)
-- [Stack Walking](stackwalking.md)
-- [Mscorlib and Calling Into the Runtime](mscorlib.md)
-- [Data Access Component (DAC) Notes](dac-notes.md)
-- [Profiling](profiling.md)
-- [Implementing Profilability](profilability.md)
-- [What Every Dev needs to Know About Exceptions in the Runtime](exceptions.md)
+- [Book of the Runtime FAQ](botr/botr-faq.md)
+- [Introduction to the Common Language Runtime](botr/intro-to-clr.md)
+- [Garbage Collection Design](botr/garbage-collection.md)
+- [Threading](botr/threading.md)
+- [RyuJIT Overview](botr/ryujit-overview.md)
+- [Type System](botr/type-system.md)
+- [Type Loader](botr/type-loader.md)
+- [Method Descriptor](botr/method-descriptor.md)
+- [Virtual Stub Dispatch](botr/virtual-stub-dispatch.md)
+- [Stack Walking](botr/stackwalking.md)
+- [Mscorlib and Calling Into the Runtime](botr/mscorlib.md)
+- [Data Access Component (DAC) Notes](botr/dac-notes.md)
+- [Profiling](botr/profiling.md)
+- [Implementing Profilability](botr/profilability.md)
+- [What Every Dev needs to Know About Exceptions in the Runtime](botr/exceptions.md)
 
 Decoder Rings
 =============
 
-- [.NET Core Glossary](glossary.md)
-- [.NET Filename Encyclopedia](dotnet-filenames.md)
+- [.NET Core Glossary](decoders/glossary.md)
+- [.NET Filename Encyclopedia](decoders/dotnet-filenames.md)
 
 Other Information
 =================
 
 - [CoreFX Repo documentation](https://github.com/dotnet/corefx/tree/master/Documentation)
 - [Porting to .NET Core](https://github.com/dotnet/corefx/blob/master/Documentation/support-dotnet-core-instructions.md)
-- [.NET Standards (Ecma)](dotnet-standards.md)
-- [CLR Configuration Knobs](clr-configuration-knobs.md)
+- [.NET Standards (Ecma)](miscellaneous/dotnet-standards.md)
+- [CLR Configuration Knobs](miscellaneous/clr-configuration-knobs.md)
 - [MSDN Entry for the CLR](http://msdn.microsoft.com/library/8bs2ecf4.aspx)
 - [Wikipedia Entry for the CLR](http://en.wikipedia.org/wiki/Common_Language_Runtime)
diff --git a/Documentation/botr-faq.md b/Documentation/botr/botr-faq.md
index b1a1de4c13..b1a1de4c13 100644
--- a/Documentation/botr-faq.md
+++ b/Documentation/botr/botr-faq.md
diff --git a/Documentation/dac-notes.md b/Documentation/botr/dac-notes.md
index 0a1a804fb3..f1f64375c6 100644
--- a/Documentation/dac-notes.md
+++ b/Documentation/botr/dac-notes.md
@@ -58,7 +58,7 @@ DAC marshaling works through a collection of typedefs, macros and templated type
 
 An example may be helpful in understanding how marshaling works. The common debugging scenario is represented in the following block diagram:
 
-![DAC Overview](images/dac-overview.png)
+![DAC Overview](../images/dac-overview.png)
 
 The debugger in this figure could be Visual Studio, MDbg, WinDbg, etc. The debugger interfaces with the CLR debugger interface (DBI) APIs to get the information it needs. Information that must come from the target goes through the DAC. The debugger implements the data target, which is responsible for implementing a ReadVirtual function to read memory in the target. The dotted line in the diagram represents the process boundary.
 
diff --git a/Documentation/exceptions.md b/Documentation/botr/exceptions.md
index daa684bf8b..daa684bf8b 100644
--- a/Documentation/exceptions.md
+++ b/Documentation/botr/exceptions.md
diff --git a/Documentation/garbage-collection.md b/Documentation/botr/garbage-collection.md
index 5b776118da..5b776118da 100644
--- a/Documentation/garbage-collection.md
+++ b/Documentation/botr/garbage-collection.md
diff --git a/Documentation/intro-to-clr.md b/Documentation/botr/intro-to-clr.md
index 3f9ce90c93..3f9ce90c93 100644
--- a/Documentation/intro-to-clr.md
+++ b/Documentation/botr/intro-to-clr.md
diff --git a/Documentation/method-descriptor.md b/Documentation/botr/method-descriptor.md
index 0e1bca096b..fec5a2661f 100644
--- a/Documentation/method-descriptor.md
+++ b/Documentation/botr/method-descriptor.md
@@ -50,11 +50,11 @@ P/Invoke methods. These are methods marked with DllImport attribute.
 
 **EEImpl**
 
-Delegate methods whose implementation is provided by the runtime (Invoke, BeginInvoke, EndInvoke). See [ECMA 335 Partition II - Delegates](dotnet-standards.md).
+Delegate methods whose implementation is provided by the runtime (Invoke, BeginInvoke, EndInvoke). See [ECMA 335 Partition II - Delegates](../miscellaneous/dotnet-standards.md).
 
 **Array**
 
-Array methods whose implementation is provided by the runtime (Get, Set, Address). See [ECMA Partition II – Arrays](dotnet-standards.md).
+Array methods whose implementation is provided by the runtime (Get, Set, Address). See [ECMA Partition II – Arrays](../miscellaneous/dotnet-standards.md).
 
 **ComInterop**
 
@@ -87,7 +87,7 @@ Each MethodDesc has a slot, which contains the entry point of the method. The sl
 
 The slot is either in MethodTable or in MethodDesc itself. The location of the slot is determined by `mdcHasNonVtableSlot` bit on MethodDesc.
 
-The slot is stored in MethodTable for methods that require efficient lookup via slot index, e.g. virtual methods or methods on generic types. The MethodDesc contains the slot index to allow fast lookup of the entry point in this case. 
+The slot is stored in MethodTable for methods that require efficient lookup via slot index, e.g. virtual methods or methods on generic types. The MethodDesc contains the slot index to allow fast lookup of the entry point in this case.
 
 Otherwise, the slot is part of the MethodDesc itself. This arrangement improves data locality and saves working set. Also, it is not even always possible to preallocate a slot in a MethodTable upfront for dynamically created MethodDescs, such as for methods added by Edit & Continue, instantiations of generic methods or [dynamic methods](https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Reflection/Emit/DynamicMethod.cs).
 
@@ -96,7 +96,7 @@ MethodDesc Chunks
 
 The MethodDescs are allocated in chunks to save space. Multiple MethodDesc tend to have identical MethodTable and upper bits of metadata token. MethodDescChunk is formed by hoisting the common information in front of an array of multiple MethodDescs. The MethodDesc contains just the index of itself in the array.
 
-![Figure 1](images/methoddesc-fig1.png)
+![Figure 1](../images/methoddesc-fig1.png)
 
 Figure 1 MethodDescChunk and MethodTable
 
@@ -175,7 +175,7 @@ The worker code of the stub is wrapped by a precode fragment that can be mapped
 
 **Temporary entry points:** Methods must provide entry points before they are jitted so that jitted code has an address to call them. These temporary entry points are provided by precode. They are a specific form of stub wrappers.
 
-This technique is a lazy approach to jitting, which provides a performance optimization in both space and time. Otherwise, the transitive closure of a method would need to be jitted before it was executed. This would be a waste, since only the dependencies of taken code branches (e.g. if statement) require jitting. 
+This technique is a lazy approach to jitting, which provides a performance optimization in both space and time. Otherwise, the transitive closure of a method would need to be jitted before it was executed. This would be a waste, since only the dependencies of taken code branches (e.g. if statement) require jitting.
 
 Each temporary entry point is much smaller than a typical method body. They need to be small since there are a lot of them, even at the cost of performance. The temporary entry points are executed just once before the actual code for the method is generated.
 
@@ -185,13 +185,13 @@ The **stable entry point** is either the native code or the precode. The **nativ
 
 Temporary entry points are never saved into NGen images. All entry points in NGen images are stable entry points that are never changed. It is an important optimization that reduced private working set.
 
-![Figure 2](images/methoddesc-fig2.png)
+![Figure 2](../images/methoddesc-fig2.png)
 
 Figure 2 Entry Point State Diagram
 
 A method can have both native code and precode if there is a need to do work before the actual method body is executed. This situation typically happens for NGen image fixups. Native code is an optional MethodDesc slot in this case. This is necessary to lookup the native code of the method in a cheap uniform way.
 
-![Figure 3](images/methoddesc-fig3.png)
+![Figure 3](../images/methoddesc-fig3.png)
 
 Figure 3 The most complex case of Precode, Stub and Native Code
 
@@ -285,7 +285,7 @@ Compact entry point is a space efficient implementation of temporary entry point
 
 Temporary entry points implemented using StubPrecode or FixupPrecode can be patched to point to the actual code. Jitted code can call temporary entry point directly. The temporary entry point can be multicallable entry points in this case.
 
-Compact entry points cannot be patched to point to the actual code. Jitted code cannot call them directly. They are trading off speed for size. Calls to these entry points are indirected via slots in a table (FuncPtrStubs) that are patched to point to the actual entry point eventually. A request for a multicallable entry point allocates a StubPrecode or FixupPrecode on demand in this case. 
+Compact entry points cannot be patched to point to the actual code. Jitted code cannot call them directly. They are trading off speed for size. Calls to these entry points are indirected via slots in a table (FuncPtrStubs) that are patched to point to the actual entry point eventually. A request for a multicallable entry point allocates a StubPrecode or FixupPrecode on demand in this case.
 
 The raw speed difference is the cost of an indirect call for a compact entry point vs. the cost of one direct call and one direct jump on the given platform. The the later used to be faster  by a few percent in large server scenario since it can be predicted by the hardware better (2005). It is not always the case on current (2015) hardware.
 
diff --git a/Documentation/mscorlib.md b/Documentation/botr/mscorlib.md
index 23c0853b49..5b5046e5bc 100644
--- a/Documentation/mscorlib.md
+++ b/Documentation/botr/mscorlib.md
@@ -174,7 +174,7 @@ FCalls require a lot of glue, too much to describe here. Look at [fcall.h][fcall
 
 ### GC Holes, FCall, and QCall
 
-A much more complete discussion on GC holes can be found in the [CLR Code Guide](clr-code-guide.md). Look for ["Is your code GC-safe?"](clr-code-guide.md#is-your-code-gc-safe). This tailored discussion motivates some of the reasons why FCall and QCall have some of their strange conventions.
+A much more complete discussion on GC holes can be found in the [CLR Code Guide](../coding-guidelines/clr-code-guide.md). Look for ["Is your code GC-safe?"](../coding-guidelines/clr-code-guide.md#is-your-code-gc-safe). This tailored discussion motivates some of the reasons why FCall and QCall have some of their strange conventions.
 
 Object references passed as parameters to FCall methods are not GC-protected, meaning that if a GC occurs, those references will point to the old location in memory of an object, not the new location. For this reason, FCalls usually follow the discipline of accepting something like "StringObject*" as their parameter type, then explicitly converting that to a STRINGREF before doing operations that may trigger a GC. You must GC protect object references before triggering a GC, if you expect to be able to use that object reference later.
 
diff --git a/Documentation/profilability.md b/Documentation/botr/profilability.md
index 528c3f1e07..528c3f1e07 100644
--- a/Documentation/profilability.md
+++ b/Documentation/botr/profilability.md
diff --git a/Documentation/profiling.md b/Documentation/botr/profiling.md
index b66e236cdd..b66e236cdd 100644
--- a/Documentation/profiling.md
+++ b/Documentation/botr/profiling.md
diff --git a/Documentation/ryujit-overview.md b/Documentation/botr/ryujit-overview.md
index 1ebcb03fbe..9596a5efa3 100644
--- a/Documentation/ryujit-overview.md
+++ b/Documentation/botr/ryujit-overview.md
@@ -38,7 +38,7 @@ The RyuJIT IR can be described at a high level as follows:
   * It includes the type of the node, as well as value number, assertions, and register assignments when available.
 * `LclVarDsc` represents a local variable, argument or JIT-created temp. It has a `gtLclNum` which is the identifier usually associated with the variable in the JIT and its dumps. The `LclVarDsc` contains the type, use count, weighted use count, frame or register assignment etc. These are often referred to simply as “lclVars”. They can be tracked (`lvTracked`), in which case they participate in dataflow analysis, and have a different index (`lvVarIndex`) to allow for the use of dense bit vectors.
 
-![RyuJIT IR Overview](images/ryujit-ir-overview.png)
+![RyuJIT IR Overview](../images/ryujit-ir-overview.png)
 
 The IR has two modes:
 
@@ -46,7 +46,7 @@ The IR has two modes:
 * In linear-order mode, non-statement nodes have both parent-child links as well as execution order links (`gtPrev` and `gtNext`).
   * In the interest of maintaining functionality that depends upon the validity of the tree ordering, the linear mode of the `GenTree` IR has an unusual constraint that the execution order must represent a valid traversal of the parent-child links.
 
-A separate representation, `insGroup` and `instrDesc`, is used during the actual instruction encoding. 
+A separate representation, `insGroup` and `instrDesc`, is used during the actual instruction encoding.
 
 ### Statement Order
 
@@ -76,26 +76,26 @@ For this snippet of code (extracted from [tests/src/JIT/CodeGenBringUpTests/DblR
 A stripped-down dump of the `GenTree` nodes just after they are imported looks like this:
 
     ▌ stmtExpr  void  (top level) (IL 0x000...0x026)
-    │        ┌──▌ lclVar    double V00 arg0         
+    │        ┌──▌ lclVar    double V00 arg0
     │     ┌──▌ *         double
     │     │  └──▌ dconst    double 2.00
     │  ┌──▌ /         double
     │  │  │  ┌──▌ mathFN    double sqrt
-    │  │  │  │  │     ┌──▌ lclVar    double V02 arg2         
+    │  │  │  │  │     ┌──▌ lclVar    double V02 arg2
     │  │  │  │  │  ┌──▌ *         double
-    │  │  │  │  │  │  │  ┌──▌ lclVar    double V00 arg0         
+    │  │  │  │  │  │  │  ┌──▌ lclVar    double V00 arg0
     │  │  │  │  │  │  └──▌ *         double
     │  │  │  │  │  │     └──▌ dconst    double 4.00
     │  │  │  │  └──▌ -         double
-    │  │  │  │     │       lclVar    double V01 arg1         
+    │  │  │  │     │       lclVar    double V01 arg1
     │  │  │  │     └──▌ *         double
-    │  │  │  │        └──▌ lclVar    double V01 arg1         
+    │  │  │  │        └──▌ lclVar    double V01 arg1
     │  │  └──▌ +         double
     │  │     └──▌ unary -   double
-    │  │        └──▌ lclVar    double V01 arg1         
+    │  │        └──▌ lclVar    double V01 arg1
     └──▌  =         double
        └──▌ indir     double
-          └──▌ lclVar    byref  V03 arg3      
+          └──▌ lclVar    byref  V03 arg3
 
 ## Types
 
@@ -118,7 +118,7 @@ Static single assignment (SSA) form is constructed in a traditional manner [[1]]
 
 ## Value Numbering
 
-Value numbering utilizes SSA for lvlVar values, but also performs value numbering of expression trees. It takes advantage of type safety by not invalidating the value number for field references with a heap write, unless the write is to the same field. The IR nodes are annotated with the value numbers, which are indexes into a type-specific value number store. Value numbering traverses the trees, performing symbolic evaluation of many operations. 
+Value numbering utilizes SSA for lvlVar values, but also performs value numbering of expression trees. It takes advantage of type safety by not invalidating the value number for field references with a heap write, unless the write is to the same field. The IR nodes are annotated with the value numbers, which are indexes into a type-specific value number store. Value numbering traverses the trees, performing symbolic evaluation of many operations.
 
 # Phases of RyuJIT
 
@@ -310,7 +310,7 @@ After rationalization, the nodes are presented in execution order, and the `GT_C
     └──▌  storeIndir double
 
 
-Note that the first operand of the first comma has been extracted into a separate statement, but the second comma causes an embedded statement to be created, in order to preserve execution order. 
+Note that the first operand of the first comma has been extracted into a separate statement, but the second comma causes an embedded statement to be created, in order to preserve execution order.
 
 ## <a name="lowering"/>Lowering
 
@@ -335,14 +335,14 @@ Is transformed into this, in which the addressing mode is explicit:
           ┌──▌  lclVar    ref    V00 arg0
           │  ┌──▌  lclVar    int    V03 loc1
           ├──▌  cast      long <- int
-       ┌──▌  lea(b+(i*4)+16) byref 
+       ┌──▌  lea(b+(i*4)+16) byref
     ┌──▌  indir     int
 
 The next pass annotates the nodes with register requirements, and this is done in an execution order traversal (effectively post-order) in order to ensure that the children are visited prior to the parent. It may also do some transformations that do not require the parent context, such as determining the code generation strategy for block assignments (e.g. `GT_COPYBLK`) which may become helper calls, unrolled loops, or an instruction like rep stos.
 
 The register requirements are expressed in the `TreeNodeInfo` (`gtLsraInfo`) for each node.  For example, for the `copyBlk` node in this snippet:
 
-    Source      │  ┌──▌  const(h)  long   0xCA4000 static 
+    Source      │  ┌──▌  const(h)  long   0xCA4000 static
     Destination │  ├──▌  &lclVar   byref  V04 loc4
                 │  ├──▌  const     int    34
                 └──▌  copyBlk   void
@@ -384,7 +384,7 @@ Post-conditions:
 * For all lvlVars that are register candidates:
   * `lvRegNum` = initial register location (or `REG_STK`)
   * `lvRegister` flag set if it always lives in the same register
-  * `lvSpilled` flag is set if it is ever spilled 
+  * `lvSpilled` flag is set if it is ever spilled
 * The maximum number of simultaneously-live spill locations of each type (used for spilling expression trees) has been communicated via calls to `compiler->tmpPreAllocateTemps(type)`.
 
 ## <a name="code-generation"/>Code Generation
@@ -397,7 +397,7 @@ The process of code generation is relatively straightforward, as Lowering has do
   * Otherwise, “consume” all the register operands of the node.
     * This updates the liveness information (i.e. marking a lvlVar as dead if this is the last use), and performs any needed copies.
     * This must be done in correct execution order, obeying any reverse flags (GTF_REVERSE_OPS) on the operands, so that register conflicts are handled properly.
-  * Track the live variables in registers, as well as the live stack variables that contain GC refs. 
+  * Track the live variables in registers, as well as the live stack variables that contain GC refs.
   * Produce the `instrDesc(s)` for the operation, with the current live GC references.
   * Update the scope information (debug info) at block boundaries.
 * Generate the prolog and epilog code.
@@ -436,7 +436,7 @@ Ordering:
 * After normalization the `gtStmtList` of the containing statement points to the first node to be executed.
 * Prior to normalization, the `gtNext` and `gtPrev` pointers on the expression (non-statement) `GenTree` nodes are invalid. The expression nodes are only traversed via the links from parent to child (e.g. `node->gtGetOp1()`, or `node->gtOp.gtOp1`). The `gtNext/gtPrev` links are set by `fgSetBlockOrder()`.
   * After normalization, and prior to rationalization, the parent/child links remain the primary traversal mechanism. The evaluation order of any nested expression-statements (usually assignments) is enforced by the `GT_COMMA` in which they are contained.
-* After rationalization, all `GT_COMMA` nodes are eliminated, and the primary traversal mechanism becomes the `gtNext/gtPrev` links. Statements may be embedded within other statements, but the nodes of each statement preserve the valid traversal order. 
+* After rationalization, all `GT_COMMA` nodes are eliminated, and the primary traversal mechanism becomes the `gtNext/gtPrev` links. Statements may be embedded within other statements, but the nodes of each statement preserve the valid traversal order.
 * In tree ordering:
   * The `gtPrev` of the first node (`gtStmtList`) is always null.
   * The `gtNext` of the last node (`gtStmtExpr`) is always null.
@@ -499,7 +499,7 @@ These can be set in one of three ways:
 * Setting the environment variable `COMPLUS_<flagname>`. For example, the following will set the `JitDump` flag so that the compilation of all methods named ‘Main’ will be dumped:
 
     set COMPLUS_JitDump=Main
-    
+
 * Setting the registry key `HKCU\Software\Microsoft\.NETFramework`, Value `<flagName>`, type `REG_SZ` or `REG_DWORD` (depending on the flag).
 * Setting the registry key `HKLM\Software\Microsoft\.NETFramework`, Value `<flagName>`, type `REG_SZ` or `REG_DWORD` (depending on the flag).
 
@@ -517,7 +517,7 @@ The namespace, class name, and argument types are optional, and if they are not
 
 		Main
 
-will match all methods named Main from any class and any number of arguments. 
+will match all methods named Main from any class and any number of arguments.
 
 <types> is a comma separated list of type names. Note that presently only the number of arguments and not the types themselves are used to distinguish methods. Thus, Main(Foo, Bar), and Main(int, int) will both match any main method with two arguments.
 
@@ -536,11 +536,11 @@ Below are some of the most useful `COMPLUS` variables. Where {method-list} is sp
 * `COMPLUS_JitTimeLogFile`={file name} – this specifies a log file to which timing information is written.
 * `COMPLUS_JitTimeLogCsv`={file name} – this specifies a log file to which summary timing information can be written, in CSV form.
 
-See also: [CLR Configuration Knobs](https://github.com/dotnet/coreclr/blob/master/Documentation/clr-configuration-knobs.md)
+See also: [CLR Configuration Knobs](../miscellaneous/clr-configuration-knobs.md)
 
 # Reading a JitDump
 
-One of the best ways of learning about the JIT compiler is examining a compilation dump in detail. The dump shows you all the really important details of the basic data structures without all the implementation detail of the code. Debugging a JIT bug almost always begins with a JitDump. Only after the problem is isolated by the dump does it make sense to start debugging the JIT code itself. 
+One of the best ways of learning about the JIT compiler is examining a compilation dump in detail. The dump shows you all the really important details of the basic data structures without all the implementation detail of the code. Debugging a JIT bug almost always begins with a JitDump. Only after the problem is isolated by the dump does it make sense to start debugging the JIT code itself.
 
 Dumps are also useful because they give you good places to place breakpoints. If you want to see what is happening at some point in the dump, simply search for the dump text in the source code. This gives you a great place to put a conditional breakpoint.
 
@@ -550,24 +550,24 @@ There is not a strong convention about what or how the information is dumped, bu
 
 It takes some time to learn to “read” the expression trees, which are printed with the children indented from the parent, and, for binary operators, with the first operand below the parent and the second operand above.
 
-Here is an example dump 
+Here is an example dump
 
     [000027] ------------             ▌  stmtExpr  void  (top level) (IL 0x010...  ???)
     [000026] --C-G-------             └──▌  return    double
     [000024] --C-G-------                └──▌  call      double BringUpTest.DblSqrt
-    [000021] ------------                   │     ┌──▌  lclVar    double V02 arg2         
+    [000021] ------------                   │     ┌──▌  lclVar    double V02 arg2
     [000022] ------------                   │  ┌──▌  -         double
-    [000020] ------------                   │  │  └──▌  lclVar    double V03 loc0         
+    [000020] ------------                   │  │  └──▌  lclVar    double V03 loc0
     [000023] ------------ arg0              └──▌  *         double
-    [000017] ------------                      │     ┌──▌  lclVar    double V01 arg1         
+    [000017] ------------                      │     ┌──▌  lclVar    double V01 arg1
     [000018] ------------                      │  ┌──▌  -         double
-    [000016] ------------                      │  │  └──▌  lclVar    double V03 loc0         
+    [000016] ------------                      │  │  └──▌  lclVar    double V03 loc0
     [000019] ------------                      └──▌  *         double
-    [000013] ------------                         │     ┌──▌  lclVar    double V00 arg0         
+    [000013] ------------                         │     ┌──▌  lclVar    double V00 arg0
     [000014] ------------                         │  ┌──▌  -         double
-    [000012] ------------                         │  │  └──▌  lclVar    double V03 loc0         
+    [000012] ------------                         │  │  └──▌  lclVar    double V03 loc0
     [000015] ------------                         └──▌  *         double
-    [000011] ------------                            └──▌  lclVar    double V03 loc0         
+    [000011] ------------                            └──▌  lclVar    double V03 loc0
 
 The tree nodes are indented to represent the parent-child relationship. Binary operators print first the right hand side, then the operator node itself, then the left hand side. This scheme makes sense if you look at the dump “sideways” (lean your head to the left). Oriented this way, the left hand side operator is actually on the left side, and the right hand operator is on the right side so you can almost visualize the tree if you look at it sideways. The indentation level is also there as a backup.
 
diff --git a/Documentation/stackwalking.md b/Documentation/botr/stackwalking.md
index 0eeada9c11..a976aa8c5b 100644
--- a/Documentation/stackwalking.md
+++ b/Documentation/botr/stackwalking.md
@@ -26,7 +26,7 @@ Because we control the format of the frames we're interested in (we'll delve int
 
 The following diagram illustrates a stack containing all the frames types (note that this document uses a convention where stacks grow towards the top of the page):
 
-![image](images/stack.png)
+![image](../images/stack.png)
 
 # Making Frames Crawlable
 
diff --git a/Documentation/threading.md b/Documentation/botr/threading.md
index ef2d3cd682..4eb8e34889 100644
--- a/Documentation/threading.md
+++ b/Documentation/botr/threading.md
@@ -14,7 +14,7 @@ The public Thread interface available to managed code intentionally hides the de
 
 - Managed threads are not necessarily mapped to a single native thread (and may not be mapped to a native thread at all).
 - Different operating systems expose different abstractions for native threads.
-- In principle, managed threads are "virtualized". 
+- In principle, managed threads are "virtualized".
 
 The CLR provide equivalent abstractions for managed threads, implemented by the CLR itself. For example, it does not expose the operating system's thread-local storage (TLS) mechanism, but instead provide managed "thread-static" variables. Similarly, it does not expose the native thread's "thread ID," but instead provide a "managed thread ID" which is generated independently of the OS. However, for diagnostic purposes, some details of the underlying native thread may be obtained via types in the System.Diagnostics namespace.
 
@@ -168,19 +168,19 @@ Thus entering cooperative mode in native code is discouraged. In cases where  co
 
 Similarly, GCX\_PREEMP potentially _releases_ a lock that had been held by the thread. Great care must be taken to ensure that all GC references are properly protected before entering preemptive mode.
 
-The [Rules of the Code](clr-code-guide.md) document describes the disciplines needed to ensure safety around GC mode switches.
+The [Rules of the Code](../coding-guidelines/clr-code-guide.md) document describes the disciplines needed to ensure safety around GC mode switches.
 
 Crst
 ----
 
-Just as Monitor is the preferred locking mechanism for managed code, Crst is the preferred mechanism for VM code. Like Monitor, Crst is a hybrid lock that is aware of hosts and GC modes. Crst also implements deadlock avoidance via "lock leveling," described in the [Crst Leveling chapter of the BotR](clr-code-guide.md#entering-and-leaving-crsts).
+Just as Monitor is the preferred locking mechanism for managed code, Crst is the preferred mechanism for VM code. Like Monitor, Crst is a hybrid lock that is aware of hosts and GC modes. Crst also implements deadlock avoidance via "lock leveling," described in the [Crst Leveling chapter of the BotR](../coding-guidelines/clr-code-guide.md#entering-and-leaving-crsts).
 
 It is generally illegal to acquire a Crst while in cooperative mode, though exceptions are made where absolutely necessary.
 
 Special Threads
 ===============
 
-In addition to managing threads created by managed code, the CLR creates several "special" threads for its own use. 
+In addition to managing threads created by managed code, the CLR creates several "special" threads for its own use.
 
 Finalizer Thread
 ----------------
diff --git a/Documentation/type-loader.md b/Documentation/botr/type-loader.md
index 9b108975fd..60a13cd22b 100644
--- a/Documentation/type-loader.md
+++ b/Documentation/botr/type-loader.md
@@ -26,7 +26,7 @@ cast is safe and can be done).
 This performance requirement rules out any dictionary look up
 approaches and leaves us with the following high-level architecture.
 
-![Figure 1](images/typeloader-fig1.png)
+![Figure 1](../images/typeloader-fig1.png)
 
 Figure 1 The abstract high-level object design
 
@@ -98,7 +98,7 @@ If **MyClass** fails to load, for example because it's supposed to be defined in
 
 The most universal type designation in the CLR is the **TypeHandle**. It's an abstract entity which encapsulates a pointer to either a **MethodTable** (representing "ordinary" types like **System.Object** or **List<string>** ) or a **TypeDesc** (representing byrefs, pointers, function pointers, arrays, and generic variables). It constitutes the identity of a type in that two handles are equal if and only if they represent the same type. To save space, the fact that a **TypeHandle** contains a **TypeDesc** is indicated by setting the second lowest bit of the pointer to 1 (i.e. (ptr | 2)) instead of using additional flags<sup>2</sup>. **TypeDesc** is "abstract" and has the following inheritance hierarchy.
 
-![Figure 2](images/typeloader-fig2.png)
+![Figure 2](../images/typeloader-fig2.png)
 
 Figure 2 The TypeDesc hierarchy
 
@@ -176,7 +176,7 @@ Runtime][generics-design] for more detailed explanation of load levels.
 
 In the generics-free world, everything is nice and everyone is happy because every ordinary (not represented by a **TypeDesc**) type has one **MethodTable** pointing to its associated **EEClass** which in turn points back to the **MethodTable**. All instances of the type contain a pointer to the **MethodTable** as their first field at offset 0, i.e. at the address seen as the reference value. To conserve space, **MethodDescs** representing methods declared by the type are organized in a linked list of chunks pointed to by the **EEClass**<sup>4</sup>.
 
-![Figure 3](images/typeloader-fig3.png)
+![Figure 3](../images/typeloader-fig3.png)
 
 Figure 3 Non-generic type with non-generic methods
 
@@ -287,7 +287,7 @@ that there is a considerable amount of information that they can
 share. This sharing has a positive impact on the memory footprint and
 consequently also performance.
 
-![Figure 4](images/typeloader-fig4.png)
+![Figure 4](../images/typeloader-fig4.png)
 
 Figure 4 Generic type with non-generic methods - shared EEClass
 
diff --git a/Documentation/type-system.md b/Documentation/botr/type-system.md
index 5e1a03f949..4be4d61f96 100644
--- a/Documentation/type-system.md
+++ b/Documentation/botr/type-system.md
@@ -29,7 +29,7 @@ The major algorithms contained within the type system are:
 - **LoadTypeHandle:** Primarily used for finding types.
 - **Signature parsing:** Used to compare and gather information about methods and fields.
 - **GetMethod/FieldDesc:** Used to find/load methods/fields.
-- **Virtual Stub Dispatch:** Used to find the destination of virtual calls to interfaces. 
+- **Virtual Stub Dispatch:** Used to find the destination of virtual calls to interfaces.
 
 There are significantly more ancillary data structures and algorithms that provide various bits of information to the rest of the CLR, but they are less significant to the overall understanding of the system.
 
@@ -43,14 +43,14 @@ Dependencies
 
 The type system is generally a service provided to many parts of the CLR, and most core components have some form of dependency on the behavior of the type system. This diagram describes the general dataflow that effects the type system. It is not exhaustive, but calls out the major information flows.
 
-![dependencies](images/type-system-dependencies.png)
+![dependencies](../images/type-system-dependencies.png)
 
 ### Component Dependencies
 
 The primary dependencies of the type system follow:
 
 - The **loader** needed to get the correct metadata to work with.
-- The **metadata system** provides a metadata api to gather information. 
+- The **metadata system** provides a metadata api to gather information.
 - The **security system** informs the type system whether or not certain type system structures are permitted (e.g. inheritance).
 - The **AppDomain** provides a LoaderAllocator to handle allocation behavior for the type system data structures.
 
@@ -81,7 +81,7 @@ Design Goals and Non-goals
 - Accessing information needed at runtime from executing (non-reflection) code is very fast.
 - Accessing information needed at compilation time for generating code is straightforward.
 - The garbage collector/stackwalker is able to access necessary information without taking locks, or allocating memory.
-- Minimal amounts of types are loaded at a time. 
+- Minimal amounts of types are loaded at a time.
 - Minimal amounts of a given type are loaded at type load time.
 - Type system data structures must be storable in NGEN images.
 
@@ -227,7 +227,7 @@ Major entry points are BuildMethodTable, LoadTypeHandleThrowing, CanCastTo\*, Ge
 Related Reading
 ===============
 
-- [ECMA CLI Specification](dotnet-standards.md)
+- [ECMA CLI Specification](../miscellaneous/dotnet-standards.md)
 - [Type Loader](type-loader.md) Book of the Runtime Chapter
 - [Virtual Stub Dispatch](virtual-stub-dispatch.md) Book of the Runtime Chapter
 - [MethodDesc](method-descriptor.md) Book of the Runtime Chapter
diff --git a/Documentation/virtual-stub-dispatch.md b/Documentation/botr/virtual-stub-dispatch.md
index 85c545949c..ef563bfa1a 100644
--- a/Documentation/virtual-stub-dispatch.md
+++ b/Documentation/botr/virtual-stub-dispatch.md
@@ -89,7 +89,7 @@ The slot map is a table of zero or more <_type_, [<_slot_, _scope_, (_index | sl
 
 The following is a small class structure (modeled in C#), and what the resulting implementation table and slot map would be for each class.
 
-![Figure 1](images/virtualstubdispatch-fig1.png)
+![Figure 1](../images/virtualstubdispatch-fig1.png)
 
 Thus, looking at this map, we see that the first column of the sub-maps of the slot maps correspond to the slot number in the classic virtual table view (remember that System.Object contributes four virtual methods of its own, which are omitted for clarity). Searches for method implementations are always bottom-up. Thus, if I had an object of type _B_ and I wished to invoke _I.Foo_, I would look for a mapping of _I.Foo_ starting at _B_'s slot map. Not finding it there, I would look in _A_'s slot map and find it there. It states that virtual slot 0 of _I_ (corresponding to _I.Foo_) is implemented by virtual slot 0. Then I return to _B_'s slot map and search for an implementation for slot 0, and find that it is implemented by slot 1 in its own implementation table.
 
@@ -130,7 +130,7 @@ Interface dispatch calls go through stubs. These stubs are all generated on dema
 
 There are currently three types of stubs. The below diagram shows the general control flow between these stubs, and will be explained below.
 
-![Figure 2](images/virtualstubdispatch-fig2.png)
+![Figure 2](../images/virtualstubdispatch-fig2.png)
 
 ### Generic Resolver
 
@@ -160,11 +160,11 @@ One resolve stub is created per token, but they all use a global cache. A stub-p
 
 The former interface virtual table dispatch mechanism results in a code sequence similar to this:
 
-![Figure 3](images/virtualstubdispatch-fig3.png)
+![Figure 3](../images/virtualstubdispatch-fig3.png)
 
 And the typical stub dispatch sequence is:
 
-![Figure 1](images/virtualstubdispatch-fig4.png)
+![Figure 1](../images/virtualstubdispatch-fig4.png)
 
 where expectedMT, failure and target are constants encoded in the stub.
 
diff --git a/Documentation/custom-dnx-instructions.md b/Documentation/building/custom-dnx-instructions.md
index 3cfd7904ef..3cfd7904ef 100644
--- a/Documentation/custom-dnx-instructions.md
+++ b/Documentation/building/custom-dnx-instructions.md
diff --git a/Documentation/debugging-instructions.md b/Documentation/building/debugging-instructions.md
index ffeff6a70f..ffeff6a70f 100644
--- a/Documentation/debugging-instructions.md
+++ b/Documentation/building/debugging-instructions.md
diff --git a/Documentation/freebsd-instructions.md b/Documentation/building/freebsd-instructions.md
index feb306fb64..feb306fb64 100644
--- a/Documentation/freebsd-instructions.md
+++ b/Documentation/building/freebsd-instructions.md
diff --git a/Documentation/linux-instructions.md b/Documentation/building/linux-instructions.md
index f9414e2cde..f9414e2cde 100644
--- a/Documentation/linux-instructions.md
+++ b/Documentation/building/linux-instructions.md
diff --git a/Documentation/osx-instructions.md b/Documentation/building/osx-instructions.md
index 4aa5d652df..4aa5d652df 100644
--- a/Documentation/osx-instructions.md
+++ b/Documentation/building/osx-instructions.md
diff --git a/Documentation/testing-with-corefx.md b/Documentation/building/testing-with-corefx.md
index c1894a25f7..c1894a25f7 100644
--- a/Documentation/testing-with-corefx.md
+++ b/Documentation/building/testing-with-corefx.md
diff --git a/Documentation/windows-debugging-instructions.md b/Documentation/building/windows-debugging-instructions.md
index de1d0a4def..de1d0a4def 100644
--- a/Documentation/windows-debugging-instructions.md
+++ b/Documentation/building/windows-debugging-instructions.md
diff --git a/Documentation/windows-instructions.md b/Documentation/building/windows-instructions.md
index 4cbbcedba7..4cbbcedba7 100644
--- a/Documentation/windows-instructions.md
+++ b/Documentation/building/windows-instructions.md
diff --git a/Documentation/windows-test-instructions.md b/Documentation/building/windows-test-instructions.md
index 1935ce550c..1935ce550c 100644
--- a/Documentation/windows-test-instructions.md
+++ b/Documentation/building/windows-test-instructions.md
diff --git a/Documentation/clr-code-guide.md b/Documentation/coding-guidelines/clr-code-guide.md
index 42731d38b1..42731d38b1 100644
--- a/Documentation/clr-code-guide.md
+++ b/Documentation/coding-guidelines/clr-code-guide.md
diff --git a/Documentation/clr-jit-coding-conventions.md b/Documentation/coding-guidelines/clr-jit-coding-conventions.md
index ddd5cd4822..ddd5cd4822 100644
--- a/Documentation/clr-jit-coding-conventions.md
+++ b/Documentation/coding-guidelines/clr-jit-coding-conventions.md
diff --git a/Documentation/cross-platform-performance-and-eventing.md b/Documentation/coding-guidelines/cross-platform-performance-and-eventing.md
index f55da62df9..f55da62df9 100644
--- a/Documentation/cross-platform-performance-and-eventing.md
+++ b/Documentation/coding-guidelines/cross-platform-performance-and-eventing.md
diff --git a/Documentation/dotnet-filenames.md b/Documentation/decoders/dotnet-filenames.md
index e12f05b18f..e12f05b18f 100644
--- a/Documentation/dotnet-filenames.md
+++ b/Documentation/decoders/dotnet-filenames.md
diff --git a/Documentation/glossary.md b/Documentation/decoders/glossary.md
index 85c4c9c970..a2145d36d2 100644
--- a/Documentation/glossary.md
+++ b/Documentation/decoders/glossary.md
@@ -16,6 +16,6 @@ As much as possible, we should link to the most authoritative and recent source
 * SOS: [Son of Strike](http://blogs.msdn.com/b/jasonz/archive/2003/10/21/53581.aspx). The debugging extension for DbgEng based debuggers. Uses the DAC as an abstraction layer for its operation.
 * SVR: The CLR used to be built as two variants, with one called "mscorsvr.dll", to mean the "server" version. In particular, it contained the server GC implementation, which was intended for multi-threaded apps capable of taking advantage of multiple processors. In the .NET Framework 2 release, the two variants were merged into "mscorwks.dll". The WKS version was the default, however the SVR version remained available.
 * URT: Universal Runtime. Ancient name for what ended up being .NET, is used in the WinError facility name FACILITY_URT.
-* VSD: [Virtual Stub Dispatch](virtual-stub-dispatch.md). Technique of using stubs for virtual method invocations instead of the traditional virtual method table.
+* VSD: [Virtual Stub Dispatch](../botr/virtual-stub-dispatch.md). Technique of using stubs for virtual method invocations instead of the traditional virtual method table.
 * VM: Virtual machine.
 * WKS: The CLR used to be built as two variants, with one called "mscorwks.dll", to mean the "workstation" version. In particular, it contained the client GC implementation, which was intended for single-threaded apps, independent of how many processors were on the machine. In the .NET Framework 2 release, the two variants were merged into "mscorwks.dll". The WKS version was the default, however the SVR version remained available.
diff --git a/Documentation/get-dotnetcore-dnx-linux.md b/Documentation/installing/get-dotnetcore-dnx-linux.md
index c595ce4c69..2dc5d89ad1 100644
--- a/Documentation/get-dotnetcore-dnx-linux.md
+++ b/Documentation/installing/get-dotnetcore-dnx-linux.md
@@ -7,7 +7,7 @@ These instructions are for .NET Core console apps. If you want to try out ASP.NE
 
 .NET Core NuGet packages and the .NET Core DNX SDKs are available on the [ASP.NET 'vnext' myget feed](https://www.myget.org/F/aspnetvnext), which you can more easily view on [gallery](https://www.myget.org/gallery/aspnetvnext) for the feed.
 
-You can also [build from source](linux-instructions.md). 
+You can also [build from source](../building/linux-instructions.md). 
 
 Environment
 ===========
@@ -17,11 +17,11 @@ These instructions are written assuming the Ubuntu 14.04 LTS, since that's the d
 Packages
 --------
 
-Install the `libunwind8`, `libssl-dev` and `unzip` packages: 
+Install the `libunwind8`, `libssl-dev` and `unzip` packages:
 
 	sudo apt-get install libunwind8 libssl-dev unzip
 
-You also need a latest version of Mono, which is required for DNU. This is a temporary requirement. 
+You also need a latest version of Mono, which is required for DNU. This is a temporary requirement.
 
 	sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
 	echo "deb http://download.mono-project.com/repo/debian wheezy main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
@@ -41,7 +41,7 @@ Installing DNVM
 You need DNVM to acquire a (or multiple) .NET Execution Environment (DNX) SDKs. DNVM is simply a script, which doesn't depend on .NET.
 
 	curl -sSL https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.sh | DNX_BRANCH=dev sh && source ~/.dnx/dnvm/dnvm.sh
-	 
+
 You can see the currently installed DNX versions with `dnvm list`, which will display an empty set of installed runtimes.
 
 	dnvm list
@@ -64,7 +64,7 @@ You can see the currently installed DNX versions with `dnvm list`.
 ```
 Active Version              Runtime Arch Location             Alias
 ------ -------              ------- ---- --------             -----
-  *    1.0.0-beta5-11649    coreclr x64  ~/.dnx/runtimes      
+  *    1.0.0-beta5-11649    coreclr x64  ~/.dnx/runtimes
        1.0.0-beta5-11649    mono         ~/.dnx/runtimes      default
 ```
 
@@ -82,8 +82,8 @@ public class Program
     {
         Console.WriteLine("Hello, Linux");
         Console.WriteLine("Love from CoreCLR.");
-    }   
-} 
+    }
+}
 ```
 
 Some people on the .NET Core team are partial to a demo console app on corefxlab repo which will print a picture for you. Download the [corefxlab demo](https://raw.githubusercontent.com/dotnet/corefxlab/master/demos/CoreClrConsoleApplications/HelloWorld/HelloWorld.cs) to the demo directory.
@@ -118,6 +118,6 @@ You can run your app with .NET Core, although make sure to switch to that DNX.
 
     dnvm use 1.0.0-beta5-11649 -r coreclr
 	dnx . run
-	
+
 	Hello, Linux
 	Love from CoreCLR.
diff --git a/Documentation/get-dotnetcore-dnx-osx.md b/Documentation/installing/get-dotnetcore-dnx-osx.md
index 90a62db397..0e773aa7c6 100644
--- a/Documentation/get-dotnetcore-dnx-osx.md
+++ b/Documentation/installing/get-dotnetcore-dnx-osx.md
@@ -7,7 +7,7 @@ These instructions are for .NET Core console apps. If you want to try out ASP.NE
 
 .NET Core NuGet packages and the .NET Core DNX SDKs are available on the [ASP.NET 'vnext' myget feed](https://www.myget.org/F/aspnetvnext), which you can more easily view on [gallery](https://www.myget.org/gallery/aspnetvnext) for the feed.
 
-You can also [build from source](osx-instructions.md). 
+You can also [build from source](../building/osx-instructions.md). 
 
 Installing DNVM
 ===============
@@ -40,7 +40,7 @@ You can see the currently installed DNX versions with `dnvm list`.
 ```
 Active Version              Runtime Arch Location             Alias
 ------ -------              ------- ---- --------             -----
-  *    1.0.0-beta5-11649    coreclr x64  ~/.dnx/runtimes      
+  *    1.0.0-beta5-11649    coreclr x64  ~/.dnx/runtimes
        1.0.0-beta5-11649    mono         ~/.dnx/runtimes      default
 ```
 
@@ -58,8 +58,8 @@ public class Program
     {
         Console.WriteLine("Hello, OS X");
         Console.WriteLine("Love from CoreCLR.");
-    }   
-} 
+    }
+}
 ```
 
 Some people on the .NET Core team are partial to a demo console app on corefxlab repo which will print a picture for you. Download the [corefxlab demo](https://raw.githubusercontent.com/dotnet/corefxlab/master/demos/CoreClrConsoleApplications/HelloWorld/HelloWorld.cs) to the demo directory.
diff --git a/Documentation/get-dotnetcore-dnx-windows.md b/Documentation/installing/get-dotnetcore-dnx-windows.md
index 283cd8dd14..6c252cffbd 100644
--- a/Documentation/get-dotnetcore-dnx-windows.md
+++ b/Documentation/installing/get-dotnetcore-dnx-windows.md
@@ -7,7 +7,7 @@ These instructions are for .NET Core console apps. If you want to try out ASP.NE
 
 .NET Core NuGet packages and the .NET Core DNX SDKs are available on the [ASP.NET 'vnext' myget feed](https://www.myget.org/F/aspnetvnext), which you can more easily view on [gallery](https://www.myget.org/gallery/aspnetvnext) for the feed.
 
-You can also acquire .NET Core directly via [NuGet restore](get-coreclr-windows.md) or [build from source](windows-instructions.md). 
+You can also acquire .NET Core directly via [NuGet restore](get-dotnetcore-windows.md) or [build from source](../building/windows-instructions.md). 
 
 Installing DNVM
 ===============
@@ -25,7 +25,7 @@ You can see the currently installed DNX versions with `dnvm list`, which will di
 Installing a .NET Core DNX
 ==========================
 
-It's easy to install the latest .NET Core-based DNX, using the `dnvm install` command. 
+It's easy to install the latest .NET Core-based DNX, using the `dnvm install` command.
 
 	C:\coreclr-demo> dnvm install -r coreclr latest -u
 
@@ -69,8 +69,8 @@ public class Program
     {
         Console.WriteLine("Hello, Windows");
         Console.WriteLine("Love from CoreCLR.");
-    }   
-} 
+    }
+}
 ```
 
 Some people on the .NET Core team are partial to a demo console app on corefxlab repo which will print a picture for you. Download the [corefxlab demo](https://raw.githubusercontent.com/dotnet/corefxlab/master/demos/CoreClrConsoleApplications/HelloWorld/HelloWorld.cs) to `C:\coreclr-demo`.
diff --git a/Documentation/get-dotnetcore-windows.md b/Documentation/installing/get-dotnetcore-windows.md
index 6159c41314..bf0a0ce68e 100644
--- a/Documentation/get-dotnetcore-windows.md
+++ b/Documentation/installing/get-dotnetcore-windows.md
@@ -7,7 +7,7 @@ These instructions are for .NET Core console apps. If you want to try out ASP.NE
 
 .NET Core NuGet packages are available on the [.NET Core myget feed](https://www.myget.org/F/dotnet-core), which you can more easily view on [gallery](https://www.myget.org/gallery/dotnet-core) for the feed.
 
-The preferred approach to acquire .NET Core is via the [.NET Core DNX SDK](get-dotnetcore-dnx-windows.md). It's the easiest approach. Alternatively, you can [build from source](windows-instructions.md). This "raw" approach falls between the two in difficulty.
+The preferred approach to acquire .NET Core is via the [.NET Core DNX SDK](get-dotnetcore-dnx-windows.md). It's the easiest approach. Alternatively, you can [build from source](../building/windows-instructions.md). This "raw" approach falls between the two in difficulty.
 
 NuGet Restore Packages
 ======================
@@ -60,8 +60,8 @@ public class Program
     {
         Console.WriteLine("Hello, Windows");
         Console.WriteLine("Love from CoreCLR.");
-    }   
-} 
+    }
+}
 ```
 
 **Another Option:** Some people on the .NET Core team are partial to a demo console app on corefxlab repo which will print a picture for you. To try it, download [corefxlab demo's HelloWorld.cs](https://raw.githubusercontent.com/dotnet/corefxlab/master/demos/CoreClrConsoleApplications/HelloWorld/HelloWorld.cs) to `C:\coreclr-demo`.
@@ -85,8 +85,8 @@ You need to copy the NuGet package assemblies over to the app folder. You need t
 	C:\coreclr-demo> for /r packages %k in (*.dll) do echo "%k" | findstr "\lib\any\ \lib\netcore50\ \lib\any~win\\" && copy /Y "%k" app
 
 	C:\coreclr-demo> copy packages\Microsoft.NETCore.Runtime.CoreCLR.ConsoleHost-x64.1.0.0-beta-22819\native\win\x64\CoreConsole.exe app\HelloWorld.exe
-	
-This last step might be a bit surprising, copying `CoreConsole.exe` to MyApp.exe, in this case `HelloWorld.exe`. This is closely related to compiling the app, in the instructions above, to MyApp.dll, in this case to `HelloWorld.dll`. 
+
+This last step might be a bit surprising, copying `CoreConsole.exe` to MyApp.exe, in this case `HelloWorld.exe`. This is closely related to compiling the app, in the instructions above, to MyApp.dll, in this case to `HelloWorld.dll`.
 
 We've grown very fond of creating and using managed EXEs that don't require a separate launcher with the .NET Framework on Windows. We wanted the same experience for .NET Core. To enable the experience, we created a launcher that expects a managed assembly of the same name, compiled with a static main method. As a case in point, if you run `CoreConsole.exe` without renaming it, it will expect a `CoreConsole.dll`. The renaming step, which you see above, needs to match the main assembly, compiled as a DLL, and you get an experience that feels launcher-less.
 
@@ -97,10 +97,10 @@ Lastly, if you're a Windows 7 user, you'll need to copy over some API DLLS:
 Run the demo
 ============
 
-You're ready to run Hello World! 
+You're ready to run Hello World!
 
 	C:\coreclr-demo> app\HelloWorld.exe
 	Hello, Windows
 	Love from CoreCLR.
-	
+
 Thanks for trying out CoreCLR. Feel free to try a more interesting demo.
diff --git a/Documentation/clr-complus-conf-docgen.sh b/Documentation/miscellaneous/clr-complus-conf-docgen.sh
index b686dca0ab..b686dca0ab 100755..100644
--- a/Documentation/clr-complus-conf-docgen.sh
+++ b/Documentation/miscellaneous/clr-complus-conf-docgen.sh
diff --git a/Documentation/clr-configuration-knobs.md b/Documentation/miscellaneous/clr-configuration-knobs.md
index b7f456b6d0..b7f456b6d0 100644
--- a/Documentation/clr-configuration-knobs.md
+++ b/Documentation/miscellaneous/clr-configuration-knobs.md
diff --git a/Documentation/dotnet-standards.md b/Documentation/miscellaneous/dotnet-standards.md
index 452c703f0a..452c703f0a 100644
--- a/Documentation/dotnet-standards.md
+++ b/Documentation/miscellaneous/dotnet-standards.md
diff --git a/Documentation/jit-testing.md b/Documentation/miscellaneous/jit-testing.md
index 63c6a63dd9..63c6a63dd9 100644
--- a/Documentation/jit-testing.md
+++ b/Documentation/miscellaneous/jit-testing.md
diff --git a/Documentation/contributing-workflow.md b/Documentation/project-docs/contributing-workflow.md
index aabc6f5c00..aabc6f5c00 100644
--- a/Documentation/contributing-workflow.md
+++ b/Documentation/project-docs/contributing-workflow.md
diff --git a/Documentation/contributing.md b/Documentation/project-docs/contributing.md
index 34b67c1859..34b67c1859 100644
--- a/Documentation/contributing.md
+++ b/Documentation/project-docs/contributing.md
diff --git a/Documentation/developer-guide.md b/Documentation/project-docs/developer-guide.md
index c35236d0a9..af47d9e566 100644
--- a/Documentation/developer-guide.md
+++ b/Documentation/project-docs/developer-guide.md
@@ -10,12 +10,12 @@ The CoreCLR repo can be built from a regular, non-admin command prompt. The buil
 
 | Chip  | Windows | Linux | OS X |
 | :---- | :-----: | :---: | :--: |
-| x64   | &#x25CF;| &#x25D2;| &#x25D2; |		  
+| x64   | &#x25CF;| &#x25D2;| &#x25D2; |
 | x86   | &#x25EF;| &#x25EF;| &#x25EF;|
 | ARM32 | &#x25EF; | &#x25EF;| &#x25EF; |
 |       | [Instructions](windows-instructions.md) | [Instructions](linux-instructions.md) | [Instructions](osx-instructions.md) |  
 
-The CoreCLR 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 [CoreCLR Issues](https://github.com/dotnet/coreclr/issues) to find out about specific work items or report issues.
+The CoreCLR 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 [CoreCLR Issues](https://github.com/dotnet/coreclr/issues) to find out about specific work items or report issues.
 
 Understanding the TFS-Git Mirror
 ================================
diff --git a/Documentation/garbage-collector-guidelines.md b/Documentation/project-docs/garbage-collector-guidelines.md
index 66d4c69b9f..66d4c69b9f 100644
--- a/Documentation/garbage-collector-guidelines.md
+++ b/Documentation/project-docs/garbage-collector-guidelines.md
diff --git a/Documentation/performance-guidelines.md b/Documentation/project-docs/performance-guidelines.md
index addaa3fe8f..addaa3fe8f 100644
--- a/Documentation/performance-guidelines.md
+++ b/Documentation/project-docs/performance-guidelines.md
diff --git a/Documentation/project-priorities.md b/Documentation/project-docs/project-priorities.md
index bb49427227..bb49427227 100644
--- a/Documentation/project-priorities.md
+++ b/Documentation/project-docs/project-priorities.md
diff --git a/README.md b/README.md
index 91d80790d0..5d477865a7 100644
--- a/README.md
+++ b/README.md
@@ -16,8 +16,8 @@ Get .NET Core
 
 |                     |Linux   |Windows |Mac OS X |FreeBSD  |
 |---------------------|--------|--------|---------|---------|
-|Build from **Source**| [Instructions](Documentation/linux-instructions.md) | [Instructions](Documentation/windows-instructions.md) | [Instructions](Documentation/osx-instructions.md) | [Instructions](Documentation/freebsd-instructions.md) |
-|Get **Binaries**     | [DNX SDK](Documentation/get-dotnetcore-dnx-linux.md)|[DNX SDK](Documentation/get-dotnetcore-dnx-windows.md) <br> [Raw](Documentation/get-dotnetcore-windows.md)|[DNX SDK](Documentation/get-dotnetcore-dnx-osx.md)||
+|Build from **Source**| [Instructions](Documentation/building/linux-instructions.md) | [Instructions](Documentation/building/windows-instructions.md) | [Instructions](Documentation/building/osx-instructions.md) | [Instructions](Documentation/building/freebsd-instructions.md) |
+|Get **Binaries**     | [DNX SDK](Documentation/installing/get-dotnetcore-dnx-linux.md)|[DNX SDK](Documentation/installing/get-dotnetcore-dnx-windows.md) <br> [Raw](Documentation/installing/get-dotnetcore-windows.md)|[DNX SDK](Documentation/installing/get-dotnetcore-dnx-osx.md)||
 
 Chat Room
 ---------
@@ -32,11 +32,11 @@ Learn about CoreCLR and .NET Core
 The best ways to learn about CoreCLR are to try out the product instructions and to read the "Book of the Runtime" architecture documents that describe the inner workings of the product. New devs to the CLR team are encouraged to read these documents before making substative changes to the product. They are equally useful for open source contributors.
 
 - [Product instructions](Documentation/README.md)
-- [Introduction to the Common Language Runtime](Documentation/intro-to-clr.md)
+- [Introduction to the Common Language Runtime](Documentation/botr/intro-to-clr.md)
 - [Book of the Runtime](Documentation/README.md#book-of-the-runtime)
 - [CoreCLR Documents](Documentation)
 
-.NET Core is part of ASP.NET 5 and is a subset of the .NET Framework. You can learn more about .NET Core and how and where you can use it in the [CoreCLR is open source][coreclr blog post] blog post. 
+.NET Core is part of ASP.NET 5 and is a subset of the .NET Framework. You can learn more about .NET Core and how and where you can use it in the [CoreCLR is open source][coreclr blog post] blog post.
 
 The [.NET Core Libraries][corefx] repo contains the base class libraries, which provides data types and base functionality (ex: String, Collections, HttpClient) on top of CoreCLR. The two repos together make up .NET Core. The [.NET Core is Open Source][.NET Core oss] and [Introducing .NET Core][Introducing .NET Core] blog posts describes our .NET Core OSS strategy and road map in more detail.
 
@@ -49,8 +49,8 @@ Looking for something to work on? The list of [up-for-grabs issues](https://gith
 
 Please read the following documents to get started.
 
-* [Contributing Guide](Documentation/contributing.md)
-* [Developer Guide](Documentation/developer-guide.md)
+* [Contributing Guide](Documentation/project-docs/contributing.md)
+* [Developer Guide](Documentation/project-docs/developer-guide.md)
 
 License
 -------