Convert wiki to docs

CONTRIBUTING.md

@@ -1,11 +1,8 @@
 # Contributing
 
-See [Contributing] on the wiki for information about coding styles, source structure, making
+See [Contributing](contributing.md) on the wiki for information about coding styles, source structure, making
 pull requests, and more.
 
-[Contributing]: https://github.com/dotnet/corefx/wiki/Contributing
 # Developers
 
-See the [Developer Guide] for details about developing in this repo.
-
-[Developer Guide]: https://github.com/dotnet/corefx/wiki/Developer-Guide
+See the [Developer Guide](developer-guide.md) for details about developing in this repo.

Documentation/README.md

@@ -0,0 +1,58 @@
+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
+============
+
+- [Developer Guide](developer-guide.md)
+- [Project priorities](https://github.com/dotnet/coreclr/blob/master/Documentation/project-priorities.md)
+- [Contributing to CoreFX](contributing.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)
+- [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
@@ -18,7 +21,7 @@ For trivial code changes, such as typo fixes, we want folks to directly submit a
 
 For work that involves adding new APIs we'd like the issue to contain what we call a *speclet*. The speclet should provide a rough sketch of how the APIs are intended to be used, with sample code that shows typical scenarios. The goal isn't to be complete but rather to illustrate the direction so that readers can judge whether the proposal is sound. Here is [a good example](https://github.com/dotnet/corefx/issues/271).
 
-![API Review Process](img/API-Review-Process.png)
+![API Review Process](images/api-review-process.png)
 
 ## Steps
 
@@ -30,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.
 

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

@@ -1,3 +1,6 @@
+Branching Guide
+===============
+
 We will have the following branches in the corefx repository:
 
 * **master**
@@ -21,5 +24,3 @@ We will have the following branches in the corefx repository:
  * Submit PRs here only if you've made prior arrangements to work on something in one of these branches.
  * It is up to the developers creating these branches to decide what level of review is required
  * These features will only ship if they are successfully pulled to master or future via the standard PR and API review process.
-
-

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.
@@ -56,4 +59,4 @@ This bucket is painful for the machine-wide .NET Framework, but we do have much
 * All bucket 1, 2, and 3 breaking changes require talking to the repo owners first.
 * If you're not sure in which bucket applies to a given change, contact us as well.
 * It doesn't matter if the old behavior is "wrong", we still need to think through the implications.
-* If a change is deemed too breaking, we can help identify alternatives such as introducing a new API and obsoleting the old one.
+* If a change is deemed too breaking, we can help identify alternatives such as introducing a new API and obsoleting the old one.

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). 
@@ -124,4 +125,4 @@ namespace System.Collections.Generics
         ...
     }
 }
-```
+```

Documentation/contributing.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](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](branching-guide.md).

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)?
 
@@ -22,4 +25,4 @@ When the whole type is for a particular platform, we've been using the prefix, e
 
 #### When should define statements be used rather than including different source files in the build environment?
 
-We're striving to avoid defines whenever possible, instead preferring to include just the source files that are relevant.
+We're striving to avoid defines whenever possible, instead preferring to include just the source files that are relevant.

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   | ●| ◒| ◒ |		  
+| x86   | ◯| ◯| ◯|
+| ARM32 | ◯ | ◯| ◯ |
+|       | [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.

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
@@ -309,4 +310,4 @@ conformance to the [Framework Design Guidelines][FDG].
 ## Presentations
 
 * [Overview of the Framework Design Guidelines](http://blogs.msdn.com/kcwalina/archive/2007/03/29/1989896.aspx)
-* [TechEd 2007 Presentation about framework engineering](http://blogs.msdn.com/kcwalina/archive/2008/01/08/FrameworkEngineering.aspx)
+* [TechEd 2007 Presentation about framework engineering](http://blogs.msdn.com/kcwalina/archive/2008/01/08/FrameworkEngineering.aspx)

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,5 +1,7 @@
-# General Information
-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.
+Building CoreFX on Linux
+========================
+
+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.
 
@@ -73,4 +75,4 @@ System.Diagnostics.FileVersionInfo.Tests.csproj does not build on Unix. https://
 
 System.Diagnostics.Debug.Tests does not build on Unix. https://github.com/dotnet/corefx/issues/1609
 
-Mono fails when trying to get custom attributes on CoreFx assemblies. https://bugzilla.xamarin.com/show_bug.cgi?id=29679
+Mono fails when trying to get custom attributes on CoreFx assemblies. https://bugzilla.xamarin.com/show_bug.cgi?id=29679