writing more docs!

.vscode/settings.json

@@ -0,0 +1,4 @@
+// Place your settings in this file to overwrite default and user settings.
+{
+		"editor.wrappingColumn": 0
+}

Breaking-Changes.md

@@ -1,8 +1,6 @@
 
 # Breaking Changes
 
-We take breaking changes seriously and will outline them for each milestone in this document. 
+We take breaking changes seriously and will outline them for each milestone in this document. As we are still pre "1.0" you can expect that there may be sweeping changes before we lockown the API set. 
-As we are still pre "1.0" you can expect that there may be sweeping changes before we lock
-down the API set. 
 
 ## 0.11.0

Contributor-License-Agreement.md

@@ -1,20 +1,8 @@
 #Contributor License Agreement
-You must sign a Contribution License Agreement (CLA) 
+You must sign a Contribution License Agreement (CLA) before your PR will be merged. This a one-time requirement for Microsoft projects in github. You can read more about Contribution License Agreements (CLA)][https://en.wikipedia.org/wiki/Contributor_License_Agreement) on wikipedia.
-before your PR will be merged. This a one-time requirement 
-for Microsoft projects in github. You can read more about 
-[Contribution License Agreements (CLA)](https://en.wikipedia.org/wiki/Contributor_License_Agreement) 
-on wikipedia.
 
-However, you don't have to do this up-front. You can simply 
+However, you don't have to do this up-front. You can simply clone, fork, and submit your pull-request as usual.
-clone, fork, and submit your pull-request as usual.
 
-When your pull-request is created, it is classified by a CLA 
+When your pull-request is created, it is classified by a CLA bot. If the change is trivial, i.e. you just fixed a typo, then the PR is labelled with `cla-not-required`. Otherwise, it's classified as `cla-required`. In that case, the system will also tell you how you can sign the CLA. Once you have signed a CLA, the current and all future pull-requests will be labelled as `cla-signed`.
-bot. If the change is trivial, i.e. you just fixed a typo, 
-then the PR is labelled with `cla-not-required`. Otherwise 
-it's classified as `cla-required`. In that case, the system 
-will also tell you how you can sign the CLA. Once you have
-signed a CLA, the current and all future pull-requests will 
-be labelled as `cla-signed`.
 
-Signing the CLA might sound scary but it's actually very 
+Signing the CLA might sound scary but it's actually very simple and can be done in less than a minute.
-simple and can be done in less than a minute.

Home.md

@@ -1,12 +1,8 @@
 
 ## Welcome
-Welcome to the VSCode Wiki. These pages are primarily intended for those 
+Welcome to the VSCode Wiki. These pages are primarily intended for those who wish to contribute to the VS Code project by submitting bug reports, suggesting new features, building extensions, commenting on new ideas, or even by submitting pull requests.
-who wish to contribute to the VS Code project by submitting bug reports, 
-suggesting new features, building extensions, commenting on new ideas, 
-or even by submitting pull requests.
 
-If you simply want more information on using Code, please visit our 
+If you simply want more information on using Code, please visit our [homepage](http://code.visualstudio.com) and follow us on [twitter](https://twitter.com/code)!
-[homepage](http://code.visualstudio.com) and follow us on [twitter](https://twitter.com/code)!
 
 ## Project Overview
 * [[Roadmap]]

How-to-Contribute.md

@@ -2,8 +2,7 @@ There are three great ways to contribute to the VS Code project: logging bugs, s
 
 ## Logging Bugs
 To log a bug, just use the [GitHub issue tracker](https://github.com/microsoft/vscode/issues). 
-Confirmed bugs will be labelled with the `Bug` label. Please do a search to see if the issue has been reported 
+Confirmed bugs will be labelled with the `Bug` label. Please do a search to see if the issue has been reported already and if not, all of the following are helpful so we can better reproduce the problem.
-already and if not, all of the following are helpful so we can better reproduce the problem.
 * Code that demonstrates the issue
 * Verison of Code
 * Description of what you expect to happen
@@ -13,21 +12,11 @@ already and if not, all of the following are helpful so we can better reproduce
 Don't feel bad if we can't reproduce the issue and ask for more information!
 
 ## Pull Requests
-Before we can accept a pull request from you, you'll need to sign a 
+Before we can accept a pull request from you, you'll need to sign a [[Contributor License Agreement (CLA)|Contributor-License-Agreement]]. It is an automated process and you only need to do it once. The project [README.md](https://github.com/Microsoft/vscode/blob/master/README.md) details how to clone, build, run, debug and test Code. Be sure to follow our [[Coding Guidelines|Coding-Guidelines]].
-[[Contributor License Agreement (CLA)|Contributor-License-Agreement]]. It is an automated process
-and you only need to do it once. The project [README.md](https://github.com/Microsoft/vscode/blob/master/README.md)
-details how to clone, build, run, debug and test Code. Be sure to follow our 
-[[Coding Guidelines|Coding-Guidelines]].
 
 ## Suggestions
-We're also interested in your feedback in future of Code. You can 
+We're also interested in your feedback in future of Code. You can submit a suggestion or feature request through the issue tracker. To make this process more effective, we're asking that these include more information to help define them more clearly. 
-submit a suggestion or feature request through the issue tracker. 
-To make this process more effective, we're asking that these include
-more information to help define them more clearly. 
 
 ## Discussion Etiquette
 
-In order to keep the conversation clear and transparent, please 
+In order to keep the conversation clear and transparent, please limit discussion to English and keep things on topic with the issue. Be considerate to others and try to be courteous and professional at all times.
-limit discussion to English and keep things on topic with the issue. 
-Be considerate to others and try to be courteous and professional 
-at all times.

Issue-Tracking-Workflow.md

@@ -2,47 +2,35 @@
 
 When you submit an issue, here's what will happen.
 
-We'll be using Labels to track the status of suggestions or feature requests. You can expect to see the following:
+We use Labels to track the status of suggestions or feature requests. You can expect to see the following:
 
 `[empty]`
 
-Issues that are unlabelled have not been looked at by a VS Code coordinator. You can expect to see them labelled within a few days of being logged.
+Issues that are unlabelled have not been looked at by a VS Code team member. You can expect to see them labelled within a few days of being logged.
 
 `Bug`
 
-Issues with the `Bug` label are considered to be defects. Once they have the `Bug` label, they'll either be assigned to a developer and assigned a milestone, or put in the Community milestone, indicating that we're accepting pull requests for this bug. Community bugs are a great place to start if you're interested in making a code contribution to TypeScript.
+Issues with the `Bug` label are considered to be defects. Once they have the `Bug` label, they'll either be assigned to a developer and assigned a milestone, or put in the `Backlog` milestone, indicating we know it's an issue but we don't know when we will fix it. 
+
+The `Backlog` milestone is a good place to start if you're interested in making a contribution to Code.
 
 `Suggestion`
 
-We consider this issue to not be a bug per se, but rather a design change or feature of some sort. Any issue with this label should have at least one more label from the list below
+We consider this issue to not be a bug, but rather a design change or feature of some sort. Any issue with this label should have at least one more label from the list below:
 
-`Needs Proposal`
+> `Needs Proposal`: A full write-up is needed to explain how the feature should work.
 
-A full write-up is needed to explain how the feature should work
+> `Needs More Info`: A proposal exists, but there are follow-up questions that need to be addressed.
 
-`Needs More Info`
+>`In Discussion`: This is being discussed by the VS Code team. You can expect this phase to take at least a few weeks, depending on our schedule.
 
-A proposal exists, but there are follow-up questions that need to be addressed
+>`Ready to Implement`: The proposal is accepted and has been designed enough that it can be implemented now.
 
-`In Discussion`
+>`Accepting PRs`: We are accepting pull requests that fully implement this feature.
 
-This is being discussed by the TypeScript design team. You can expect this phase to take at least a few weeks, depending on our schedule
+>`Committed`: We have allocated time on the team schedule to implement this feature. It will have a milestone assigned as well.
 
-`Ready to Implement`
+>`Declined`: Declined suggestions will have this label along with one of the following:
-
-The proposal is accepted and has been designed enough that it can be implemented now
-
-`Accepting PRs`
-
-We are accepting pull requests that fully implement this feature
-
-`Committed`
-
-We have allocated time on the team schedule to implement this feature
-
-`Declined`
-
-Declined suggestions will have this label along with one of the following:
  * `Out of Scope`: Is outside the scope of the project and would be better implemented as a separate tool or extension
  * `Too Complex`: The amount of complexity that this (and its future implications) would introduce is not justified by the amount of value it adds
  * `Breaking Change`: Would meaningfully break compatibility with a previous version of VS Code, or would prevent us from implementing known future proposals

Planning-and-Triage-Process.md

@@ -0,0 +1,19 @@
+# The Planning Process
+Milestones are roughly month based rather than week based. We will begin a milestone on a Monday and end on a Friday, meaning that each milestone can have a different duration, depending on how the weeks align.
+
+Towards the end of of each milestone we will hold a planning meeting where we prioritize features to implement and bugs to fix in the upcoming milestone. The result of this meeting will be a set of features on the [[Roadmap]] along with a set of bugs marked to be fixed in the upcoming Milestone. Together, this encompasses the planned work for the upcoming month.
+
+Each feature will have design or description of the feature that can be contributed by, augmented, and commented upon by the community. 
+
+#  The Triage Process
+Like all software projects, we will plan to do more than we can actually get done during a milestone. This is OK, it is better to be aggressive aspire for greatness rather than being passive and settling for "good enough".
+
+Bugs and features will be assigned a milestone and within a milestone they will be assigned a priority. The priority dictates the order in which work items should be addressed. A P1 bug (something that we think is critical for the milestone) is to be addressed before a P2 bug. 
+
+# Weekly Planning
+Each week we will review our progress and reasses progress and the schedule, crossing off completed features and triaging bugs. At the end of the milestone we will strive for 0 bugs and 0 issues in the milestone, indicating we are done. This means that bugs and features will be postponed to later milestones.
+
+# End Game
+The final week of the milestone is what we call the "end game". During this week we will wrap up any feature work, we will test, and then we will fix the critical bugs for that milestone.
+
+At the end of this process we will produce a build and release it on the `insiders` update stream. We will monitor incoming issues from this release, fix any critical bugs that arise, and then produce a final release for the milestone.

Roadmap.md

@@ -1,5 +1,26 @@
+# 0.11.0
+## Schedule
 
-## 0.10.0
+| Task                      | Dates           |
+| ------------------------- | --------------- |
+| Planning                  | Nov 19          |
+| Development               | Nov 24 - Dec 17 |
+| End Game                  | Dec 07 - Dec 10 |
+| Insiders drop             | Dec 10          | 
+| Release                   | Dec 17          | 
+
+## Goals
+* React to broad extension development feedback
+* Refine development in the open workflow
+
+## Constraints
+* Holiday season
+
+## Key Initiatives
+* TBD
+
+
+# 0.10.0
 ### Schedule
 | Task                      | Dates         |
 | ------------------------- | ------------- |