Update README.md and add additional documentation.

CODE_OWNERS.txt

@@ -0,0 +1,16 @@
+The following is a list of owners for different areas of the VSCode .NET Core extension code. 
+Each of the owners is responsible for ensuring that changes in their areas 
+are reviewed, either by themselves or by someone they designate, in 
+addition to being the final word for the architecture and content of an area.
+
+List sorted by last name and the fields are Name (N), GitHub user account (G), 
+Description (D).
+
+Note: If you don't find the area in the below list, or you have a general 
+question, send a message to Livar Cunha (@livarcocc) and N. Taylor Mullen
+(@NTaylorMullen). They can ensure that the question gets forwarded to the
+right person or answer it themselves.  
+
+N: N. Taylor Mullen
+G: NTaylorMullen
+D: Everything

CONTRIBUTING.md

@@ -0,0 +1,3 @@
+# Contributing
+
+See [Contributing](Documentation/contributing.md) for information about coding styles, source structure, making pull requests, and more.

Documentation/contributing-workflow.md

@@ -0,0 +1,57 @@
+Contribution Workflow
+=====================
+
+You can contribute to .NET Core with issues and PRs. Simply filing issues for problems you encounter is a great way to contribute. Contributing implementations is greatly appreciated.
+
+## Suggested Workflow
+
+We use and recommend the following workflow:
+
+1. Create an issue for your work. 
+    - You can skip this step for trivial changes.
+    - Reuse an existing issue on the topic, if there is one.
+    - Use [CODE_OWNERS.TXT](../CODE_OWNERS.txt) to find relevant maintainers and @ mention them to ask for feedback on your issue.
+    - Get agreement from the team and the community that your proposed change is a good one.
+    - If your change adds a new API, follow the [API Review Process](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md) (but replace CoreFX with this repo). 
+    - Clearly state that you are going to take on implementing it, if that's the case. You can request that the issue be assigned to you. Note: The issue filer and the implementer don't have to be the same person.
+2. Create a personal fork of the repository on GitHub (if you don't already have one).
+3. Create a branch off of master (`git checkout -b mybranch`). 
+    - Name the branch so that it clearly communicates your intentions, such as issue-123 or githubhandle-issue. 
+    - Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork.
+4. Make and commit your changes.
+    - Please follow our [Commit Messages](contributing.md#commit-messages) guidance.
+5. Add new tests corresponding to your change, if applicable.
+6. Build the repository with your changes.
+    - Make sure that the builds are clean.
+    - Make sure that the tests are all passing, including your new tests.
+7. Create a pull request (PR) against the upstream repository's **master** branch.
+    - Push your changes to your fork on GitHub (if you haven't already).
+
+Note: It is OK for your PR to include a large number of commits. Once your change is accepted, you will be asked to squash your commits into one or some appropriately small number of commits before your PR is merged.
+
+Note: It is OK to create your PR as "[WIP]" on the upstream repo before the implementation is done. This can be useful if you'd like to start the feedback process concurrent with your implementation. State that this is the case in the initial PR comment.
+
+## PR - CI Process
+
+The [dotnet continuous integration](https://dev.azure.com/dnceng/public/) (CI) system will automatically perform the required builds and run tests (including the ones you are expected to run) for PRs. Builds and test runs must be clean.
+
+If the CI build fails for any reason, the PR issue will be updated with a link that can be used to determine the cause of the failure.
+
+## PR Feedback
+
+Microsoft team and community members will provide feedback on your change. Community feedback is highly valued. You will often see the absence of team feedback if the community has already provided good review feedback. 
+
+1 or more Microsoft team members will review every PR prior to merge. They will often reply with "LGTM, modulo comments". That means that the PR will be merged once the feedback is resolved. "LGTM" == "looks good to me".
+
+There are lots of thoughts and [approaches](https://github.com/antlr/antlr4-cpp/blob/master/CONTRIBUTING.md#emoji) for how to efficiently discuss changes. It is best to be clear and explicit with your feedback. Please be patient with people who might not understand the finer details about your approach to feedback.
+
+# Merging Pull Requests (for contributors with write access)
+
+Use ["Squash and Merge"](https://github.com/blog/2141-squash-your-commits) by default for individual contributions unless requested by the PR author.
+  Do so, even if the PR contains only one commit. It creates a simpler history than "Create a Merge Commit".
+  Reasons that PR authors may request "Merge and Commit" may include (but are not limited to):
+
+  - The change is easier to understand as a series of focused commits. Each commit in the series must be buildable so as not to break `git bisect`.
+  - Contributor is using an e-mail address other than the primary GitHub address and wants that preserved in the history. Contributor must be willing to squash
+    the commits manually before acceptance.
+

Documentation/contributing.md

@@ -0,0 +1,113 @@
+Contributing to the VSCode .NET Core Acquisition Extension
+=========================
+
+The .NET Core team maintains guidelines for contributing to the .NET Core repos. A .NET Core team member will be happy to explain why a guideline is defined as it is.
+
+General contribution guidance is included in this document. Additional guidance is defined in the documents linked below.
+
+- [Copyright](copyright.md) describes the licensing practices for the project.
+- [Contribution Workflow](contributing-workflow.md) describes the workflow that the team uses for considering and accepting changes.
+
+Up for Grabs
+------------
+
+The team marks the most straightforward issues as "up for grabs". This set of issues is the place to start if you are interested in contributing but new to the codebase.
+
+- [dotnet/vscode-dotnetcore-acquisition-extension - "up for grabs"](https://github.com/dotnet/vscode-dotnetcore-acquisition-extension/labels/up-for-grabs)
+- [dotnet/vscode-dotnetcore-acquisition-extension - "up for grabs"](https://github.com/dotnet/vscode-dotnetcore-acquisition-extension/labels/up-for-grabs)
+
+Contribution "Bar"
+------------------
+
+Project maintainers will merge changes that improve the product significantly and broadly and that align with the [.NET Core roadmap](https://github.com/dotnet/core/blob/master/roadmap.md). 
+
+Maintainers will not merge changes that have narrowly-defined benefits, due to compatibility risk. The .NET Core codebase is used by several Microsoft products (for example, ASP.NET Core, .NET Framework 4.x, Windows Universal Apps) to enable execution of managed code. Other companies are building products on top of .NET Core, too. We may revert changes if they are found to be breaking.
+
+Contributions must also satisfy the other published guidelines defined in this document.
+
+Automated Code Review Assistance
+------------------
+
+CROSS is a tool developed by Microsoft that is used to highlight areas of higher risk in a code change in order to help code reviewers do a more effective job.
+
+DOs and DON'Ts
+--------------
+
+Please do:
+
+* **DO** follow our [coding style](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md) (C# code-specific)
+* **DO** give priority to the current style of the project or file you're changing even if it diverges from the general guidelines.
+* **DO** include tests when adding new features. When fixing bugs, start with
+  adding a test that highlights how the current behavior is broken.
+* **DO** keep the discussions focused. When a new or related topic comes up
+  it's often better to create new issue than to side track the discussion.
+* **DO** blog and tweet (or whatever) about your contributions, frequently!
+
+Please do not:
+
+* **DON'T** make PRs for style changes. 
+* **DON'T** surprise us with big pull requests. Instead, file an issue and start
+  a discussion so we can agree on a direction before you invest a large amount
+  of time.
+* **DON'T** commit code that you didn't write. If you find code that you think is a good fit to add to .NET Core, file an issue and start a discussion before proceeding.
+* **DON'T** submit PRs that alter licensing related files or headers. If you believe there's a problem with them, file an issue and we'll be happy to discuss it.
+* **DON'T** add API additions without filing an issue and discussing with us first. See [API Review Process](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md).
+
+Managed Code Compatibility
+--------------------------
+
+Contributions must maintain [API signature](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/breaking-changes.md#bucket-1-public-contract) and behavioral compatibility. Contributions that include [breaking changes](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/breaking-changes.md) will be rejected. Please file an issue to discuss your idea or change if you believe that it may affect managed code compatibility.
+
+Commit Messages
+---------------
+
+Please format commit messages as follows (based on [A Note About Git Commit Messages](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)):
+
+```
+Summarize change in 50 characters or less
+
+Provide more detail after the first line. Leave one blank line below the
+summary and wrap all lines at 72 characters or less.
+
+If the change fixes an issue, leave another blank line after the final
+paragraph and indicate which issue is fixed in the specific format
+below.
+
+Fix #42
+```
+
+Also do your best to factor commits appropriately, not too large with unrelated things in the same commit, and not too small with the same small change applied N times in N different commits.
+
+Contributor License Agreement
+-----------------------------
+
+You must sign a [.NET Foundation Contribution License Agreement (CLA)](https://cla.dotnetfoundation.org) before your PR will be merged. This is a one-time requirement for projects in the .NET Foundation. You can read more about [Contribution License Agreements (CLA)](http://en.wikipedia.org/wiki/Contributor_License_Agreement) on Wikipedia.
+
+The agreement: [net-foundation-contribution-license-agreement.pdf](https://github.com/dotnet/home/blob/master/guidance/net-foundation-contribution-license-agreement.pdf)
+
+You don't have to do this up-front. You can simply clone, fork, and submit your pull-request as usual. When your pull-request is created, it is classified by a CLA bot. If the change is trivial (for example, you just fixed a typo), then the PR is labelled with `cla-not-required`. Otherwise it's classified as `cla-required`. Once you signed a CLA, the current and all future pull-requests will be labelled as `cla-signed`.
+
+File Headers
+------------
+
+The following file header is the used for .NET Core. Please use it for new files.
+
+```
+/*---------------------------------------------------------------------------------------------
+ *  Copyright (c) Microsoft Corporation. All rights reserved.
+ *  Licensed under the MIT License. See License.txt in the project root for license information.
+ *--------------------------------------------------------------------------------------------*/
+```
+
+- See [DotnetCoreAcquisitionWorker.ts](../dotnetcore-acquisition-library/src/DotnetCoreAcquisitionWorker.ts) for an example of the header in a TypeScript file.
+
+Copying Files from Other Projects
+---------------------------------
+
+.NET Core uses some files from other projects, typically where a binary distribution does not exist or would be inconvenient.
+
+The following rules must be followed for PRs that include files from another project:
+
+- The license of the file is [permissive](https://en.wikipedia.org/wiki/Permissive_free_software_licence).
+- The license of the file is left in-tact.
+- The contribution is correctly attributed in the [3rd party notices](../THIRD-PARTY-NOTICES.txt) file in the repository, as needed.

Documentation/copyright.md

@@ -0,0 +1,34 @@
+Copyright
+=========
+
+The .NET Core copyright is held by ".NET Foundation and Contributors". 
+
+The [.NET Foundation](http://www.dotnetfoundation.org/) is an independent organization that encourages open development and collaboration around the .NET ecosystem.
+
+Source License
+--------------
+
+The .NET Core project uses multiple licenses for the various project repositories.  
+
+- The [MIT License](https://opensource.org/licenses/MIT) is used by most repositories for [code](https://github.com/dotnet/coreclr/). 
+- The  [Apache 2 License](https://opensource.org/licenses/Apache-2.0) is also used by some projects for [code](https://github.com/dotnet/roslyn/). 
+- The [Creative Commons Attribution 4.0 International Public License (CC-BY)](https://creativecommons.org/licenses/by/4.0/) is used for [documentation](https://github.com/dotnet/docs/) and [swag](https://github.com/dotnet/swag). 
+
+Binary License
+--------------
+
+.NET Core distributions are licensed with a variety of licenses, dependent on the content. By default, the MIT license is used, the exact same as the [source license](https://github.com/dotnet/core/blob/master/LICENSE.TXT), with the same copyright holder. There are some cases where that isn't possible because a given component includes a proprietary Microsoft binary. This is typically only the case for Windows distributions.
+
+The following rules are used for determining the binary license:
+
+- .NET Core binary distributions (zips, nuget packages, …) are licensed as MIT (identical to the [.NET Core source license](https://github.com/dotnet/core/blob/master/LICENSE.TXT)).
+- The license link (if there is one) should point to the repository where the file came from, for example: [dotnet/corefx](https://github.com/dotnet/corefx/blob/master/LICENSE.TXT).
+- If the contained binaries are built from multiple .NET Core repositories, the license should point to [dotnet/core](https://github.com/dotnet/core/blob/master/LICENSE.TXT). 
+- If the contents are not 100% open source, the distribution should be licensed with the [.NET Library license](https://www.microsoft.com/net/dotnet_library_license.htm).
+- It is OK for licensing to be asymmetric for a single distribution type. For example, it’s possible that the .NET Core SDK distribution might be fully open source for Linux but include a closed-source component on Windows. In this case, the SDK would be licensed as MIT on Linux and use the .NET Library License on Windows. It is better to have more open licenses than less.
+- It is OK for the source and binary licenses not to match. For example, the source might be Apache 2 but ships as an MIT binary.  The third party notices file should capture the Apache 2 license. This only works for a permissive licenses, however, we have limited the project to that class of licenses already. The value of this approach is that binary licenses are uniform.
+
+Patents
+-------
+
+Microsoft has issued a [Patent Promise for .NET Libraries and Runtime Components](https://github.com/dotnet/coreclr/blob/master/PATENTS.TXT).

README.md

@@ -1,4 +1,4 @@
-# General Purpose
+# Purpose
 
 There are two top level use-cases for needing .NET Core in VSCode:
 
@@ -26,17 +26,28 @@ This repo attempts to solve the above issues.
 
 TBD
 
--------------------------------------
 
-# Building the repo
+# Contributing to Repository 
 
-## Requirements
+Looking for something to work on? The list 
+of [up-for-grabs issues](https://github.com/dotnet/vscode-dotnetcore-acquisition-extension/labels/up-for-grabs) is a great place to start.
+
+Please read the following documents to get started.
+
+* [Contributing Guide](Documentation/contributing.md)
+
+This project has adopted the code of conduct defined by the [Contributor Covenant](http://contributor-covenant.org/) 
+to clarify expected behavior in our community. For more information, see the [.NET Foundation Code of Conduct](http://www.dotnetfoundation.org/code-of-conduct).
+
+## Building the repo
+
+### Requirements
 - Node.js + npm
 - VSCode
 
-## Running the sample
+### Running the sample
 1.  Run the build script at the root of the repo (`build.sh` or `build.cmd`).
-2. Open the repo's [workspace](https://github.com/NTaylorMullen/vscode-dotnetcore-acquisition-extension/blob/d1084c0f4e86c8cee8474f6a716cfbe633b57c37/dotnetcore-acquisition.code-workspace) in VSCode
+2. Open the repo's [workspace](dotnetcore-acquisition.code-workspace) in VSCode
 3. Run the `Run Sample Extension` configuration in VSCode
 4. In the launched experimental instance open the command pallete and run the `Sample: Run a dynamically acquired .NET Core Hello World App`.
 

THIRD-PARTY-NOTICES.txt

@@ -0,0 +1,12 @@
+.NET Core uses third-party libraries or other resources that may be
+distributed under licenses different than the .NET Core software.
+
+Attributions and license notices for test cases originally authored by
+third parties can be found in the respective test directories.
+
+In the event that we accidentally failed to list a required notice, please
+bring it to our attention. Post an issue or email us:
+
+           [email protected]
+
+The attached notices are provided for information only.