Convert wiki to docs

Documentation/README.md

@@ -0,0 +1,57 @@
+Documents Index
+===============
+
+Learn about .NET Core
+====================
+
+- [Brief Intro to .NET Core](https://github.com/dotnet/coreclr/blob/master/Documentation/dotnetcore-intro.md)
+- [[WIP] Official .NET Core Docs](http://dotnet.readthedocs.org)
+
+Get .NET Core
+=============
+
+- [Get .NET Core DNX SDK on Windows](https://github.com/dotnet/coreclr/blob/master/Documentation/get-dotnetcore-dnx-windows.md)
+- [Get .NET Core DNX SDK on OS X](https://github.com/dotnet/coreclr/blob/master/Documentation/get-dotnetcore-dnx-osx.md)
+- [Get .NET Core DNX SDK on Linux](https://github.com/dotnet/coreclr/blob/master/Documentation/get-dotnetcore-dnx-linux.md)
+- [Get .NET Core (Raw) on Windows](https://github.com/dotnet/coreclr/blob/master/Documentation/get-dotnetcore-windows.md)
+
+Project Docs
+============
+
+- [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)
+- [Contributing to CoreFX](contributing-corefx.md)
+- [Issue Guide](issue-guide.md)
+- [Branching Guide](branching-guide.md)
+- [API Review Process](api-review-process.md)
+- [Strong Name Signing](strong-name-signing.md)
+- [Open Source Signing](oss-signing.md)
+- [Repo Organization](repo-organization.md)
+
+Coding Guidelines
+=================
+
+- [C# coding style](coding-style.md)
+- [Framework Design Guidelines](framework-design-guidelines-digest.md)
+- [Cross-Platform Guidelines](cross-platform-guidelines.md)
+- [Performance Guidelines](performance-guidelines.md)
+- [Interop Guidelines](interop-guidelines.md)
+- [Breaking Changes](breaking-changes.md)
+- [Breaking Change Definitions](breaking-change-definitions.md)
+- [Breaking Change Rules](breaking-change-rules.md)
+
+Building from Source
+====================
+
+- [Building on Linux](linux-instructions.md)
+- [Code Coverage](code-coverage.md)
+
+Other Information
+=================
+
+- [CoreCLR Repo documentation](https://github.com/dotnet/coreclr/tree/master/Documentation)
+- [Porting to .NET Core](support-dotnet-core-instructions.md)
+- [.NET Standards (Ecma)](https://github.com/dotnet/coreclr/blob/master/Documentation/dotnet-standards.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)

API-Review-Process.md → Documentation/api-review-process.md

@@ -1,3 +1,6 @@
+API Review Process
+==================
+
 The .NET Framework has a long standing history of taking API usability extremely seriously. Thus, we generally review every single API that is added to the product. This page discusses how we conduct API reviews for components that are open sourced.
 
 ## Process Goals

Branching-Guide.md → Documentation/branching-guide.md

@@ -1,3 +1,6 @@
+Branching Guide
+===============
+
 We will have the following branches in the corefx repository:
 
 * **master**

Breaking-Change-Definitions.md → Documentation/breaking-change-definitions.md

@@ -1,24 +1,38 @@
+Breaking Change Definitions
+===========================
+
+Behavioral Change
+-----------------
 
-**Behavioral Change**  
 A behavioral change represents changes to the behavior of a member. A behavioral change may including throwing a new exception, adding or removing internal method calls, or alternating the way in which a return value is calculated. Behavioral changes can be the hardest type of change to categorize as acceptable or not - they can be severe in impact, or relatively innocuous.
 
-**Binary Compatibility**  
+Binary Compatibility  
+--------------------
+
 Refers to the ability of existing consumers of an API to be able to use a newer version without recompilation. By definition, if an assembly's public signatures have been removed, or altered so that consumers cannot no longer access the same interface exposed by the assembly, the change is said to be a _binary incompatible change_.
 
-**Source Compatibility**  
+Source Compatibility
+--------------------
+
 Refers to the ability of existing consumers of an API to recompile against a newer version without any source changes. By definition, if a consumer needs to make changes to its code in order to for it build successfully against a newer version of an API, the change is said to be a _source incompatible change_.
 
-**Design-Time Compatibility**  
+Design-Time Compatibility  
+-------------------------
+
 _Design-time compatibility_ refers to preserving the design-time experience across versions of Visual Studio and other design-time environments. This can involve details around the UI of the designer, but by far the most interesting design-time compatibility is project compatibility. A potential project (or solution), must be able to be opened, and used on a newer version of a designer.
 
-**Backwards Compatibility**  
+Backwards Compatibility  
+-----------------------
+
 _Backwards compatibility_ refers to the ability of an existing consumer of an API to run against, and behave in the same way against a newer version. By definition, if a consumer is not able to run, or behaves differently against the newer version of the API, then the API is said to be _backwards incompatible_. 
 
 Changes that affect backwards compatibility are strongly discouraged. All alternates should be actively considered, since developers will, by default, expect backwards compatibility in newer versions of an API.
 
-**Forwards Compatibility**  
+Forwards Compatibility  
+----------------------
+
 _Forwards compatibility_ is the exact reverse of backwards compatibility; it refers to the ability of an existing consumer of an API to run against, and behave in the way against a _older_ version. By definition, if a consumer is not able to run, or behaves differently against an older version of the API, then the API is said to be _forwards incompatible_.
 
 Changes that affect forwards compatibility are generally less pervasive, and there is not as stringent a demand to ensure that such changes are not introduced. Customers accept that a consumer which relies upon a newer API, may not function correctly against the older API.
 
-This wiki does not attempt to detail forwards incompatibilities.
+This document does not attempt to detail forwards incompatibilities.

Breaking-Change-Rules.md → Documentation/breaking-change-rules.md

@@ -1,4 +1,5 @@
-## Table of Contents
+Breaking Change Rules
+=====================
 
 * [Behavioral Changes](#behavioral-changes)
    * [Property, Field, Parameter and Return Values](#property-field-parameter-and-return-values)

Breaking-Changes.md → Documentation/breaking-changes.md

@@ -1,3 +1,6 @@
+Breaking Changes
+================
+
 We take compatibility in the .NET Framework and .NET Core extremely seriously.
 
 Although .NET Core can be deployed app local, we are engineering it such that portable libraries can target it and still run on the full desktop framework as well. This means that the behavior of the full .NET Framework constrains the implementation of any overlapping API in .NET Core.

Code-Coverage.md → Documentation/code-coverage.md

@@ -1,4 +1,5 @@
-## Overview
+Code Coverage
+=============
 
 "Code coverage" is a measure that indicates how much of our library code is exercised by our test suites.  We measure code coverage using the [OpenCover](https://github.com/opencover/opencover), and a report of our latest code coverage results can be seen by clicking the coverage badge on the [CoreFX home page](https://github.com/dotnet/corefx):
 

Coding-style.md → Documentation/coding-style.md

@@ -1,7 +1,8 @@
-## General guidelines
+C# Coding Style
+===============
+
 For non .cs files (c++, xml etc) our current best guidance is consistency. When editing files, keep new code and changes consistent with the style in the files. For new files, it should conform to the style for that component. Last, if there's a completely new component, anything that is reasonably broadly accepted is fine.
 
-## C# guidelines
 The general rule we follow is "use Visual Studio defaults".
 
 1. We use [Allman style](http://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and it must not be nested in other statement blocks that use braces (See issue [381](https://github.com/dotnet/corefx/issues/381) for examples). 

Documentation/contributing-corefx.md

@@ -0,0 +1,17 @@
+Contributing to CoreFX
+======================
+
+This document describes contribution guidelines that are specific to CoreFX. Please read [.NET Core Guidelines](https://github.com/dotnet/coreclr/blob/master/Documentation/contributing.md) for more general .NET Core contribution guidelines.
+
+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:
+
+* **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]].

Cross-Platform-Code-Guidelines.md → Documentation/cross-platform-guidelines.md

@@ -1,4 +1,7 @@
-This page provides a FAQ for how we handle cross-platform code in CoreFX. (For structuring of interop code, see [[Structuring Interop Code]].)
+Cross-Platform Guidelines
+=========================
+
+This page provides a FAQ for how we handle cross-platform code in CoreFX. (For structuring of interop code, see [interop guidelines](interop-guidelines.md).)
 
 #### Should assemblies be binary-compatible across platforms (e.g. exact same System.IO.dll on Windows, Linux, and Mac)?
 

Framework-Design-Guidelines-Digest.md → Documentation/framework-design-guidelines-digest.md

@@ -1,4 +1,5 @@
-# Introduction
+Framework Design Guidelines - Digest
+====================================
 
 This page is a distillation and a simplification of the most basic
 guidelines described in detail in a book titled

Structuring-Interop-Code.md → Documentation/interop-guidelines.md

@@ -1,3 +1,6 @@
+Interop Guidelines
+==================
+
 ## Goals
 We have the following goals related to interop code being used in CoreFX:
 

Issue-Guide.md → Documentation/issue-guide.md

@@ -1,4 +1,6 @@
-### Overview
+Issue Guide
+===========
+
 This page outlines how the CoreFx team thinks about and handles issues.  For us, issues on GitHub represent actionable work that should be done at some future point.  It may be as simple as a small product or test bug or as large as the work tracking the design of a new feature.  However, it should be work that falls under the charter of CoreFx, which is a collection of foundational libraries that make up the .NET Core development stack.  We will keep issues open even if the CoreFx team internally has no plans to address them in an upcoming release, as long as we consider the issue to fall under our purview.
 
 ### When we close issues
@@ -8,7 +10,7 @@ As noted above, we don't close issues just because we don't plan to address them
 2. Cross cutting work better suited for another team.  Sometimes the line between the framework, languages and runtime blurs.  For some issues, we may feel that the work is better suited for the runtime team, language team or other partner.  In these cases, we'll close the issue and open it with the partner team.  If they end up not deciding to take on the issue, we can reconsider it here.
 3. Nebulous and Large open issues.  Large open issues are sometimes better suited for [User Voice](http://visualstudio.uservoice.com/forums/121579-visual-studio/category/31481--net), especially when the work will cross the boundaries of the framework, language and runtime.  A good example of this is the SIMD support we recently added to CoreFx.  This started as a User Voice request, and eventually turned into work for both the core libraries and runtime.
 
-Sometimes after debate, we'll decide an issue isn't a good fit for CoreFx.  In that case, we'll also close it.  Because of this, we ask that you don't start working on an issue until it's tagged with "up for grabs" or "feature approved".  We'd hate for you to spend time and effort working on a change we'll ultimately be unable to take.
+Sometimes after debate, we'll decide an issue isn't a good fit for CoreFx.  In that case, we'll also close it.  Because of this, we ask that you don't start working on an issue until it's tagged with "up for grabs" or "feature approved".  Both you and the team will be unhappy if you spend time and effort working on a change we'll ultimately be unable to take. We try to avoid that.
 
 ### Labels
 We use GitHub labels on our issues in order to classify them.  We have the following categories per issue:

Building-On-Unix.md → Documentation/linux-instructions.md

@@ -1,4 +1,6 @@
-# General Information
+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.
 
 After preparing Mono, clone if you haven't already, and run the build script.

Open-Source-Signing.md → Documentation/oss-signing.md

@@ -1,3 +1,6 @@
+Open Source Signing
+===================
+
 For reasons listed over on [Strong Naming](Strong Naming), 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.

Performance.md → Documentation/performance-guidelines.md

@@ -1,3 +1,6 @@
+Managed Code Performance Guidelines
+===================================
+
 Different applications have different needs when it comes to performance.  For libraries that may be used in any of them and potentially on critical paths, however, it is of the utmost importance that code is as efficient as possible.  The code in CoreFX should strive to be high-performing, including minimizing the number and size of allocations, minimizing the number of branches involved in code, and overall minimizing the amount of work that must be done to perform any given operation.
 
 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.

Test-Orgnaization.md → Documentation/repo-organization.md

@@ -1,3 +1,6 @@
+Repo Organization
+=================
+
 Tests for a project are kept under the `tests` folder, which is a peer of the `src` folder.  If you need to have multiple test projects for a component, structure them in sub folders.
 
 For example, lay things out like this:

Strong-Naming.md → Documentation/strong-name-signing.md

@@ -1,3 +1,6 @@
+Strong Name Signing
+===================
+
 All .NET Core assemblies are [strong-named](http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx). We do this for two reasons:
 
 1. _Compatibility_. We want to maintain type identity with previous versions of our assemblies that have shipped across various versions of our platforms. Removing a strong-name from an assembly is a breaking change, and would break the ability to consume and run libraries built against the previous identities.

Developer-Guide.md → Documentation/windows-instructions.md

@@ -1,3 +1,6 @@
+Building CoreFX on Windows
+==========================
+
 You can build .NET Core either via the command line or by using Visual Studio.
 We currently only support building and running on Windows. Other platforms will
 come later.