several additions

Erich Gamma 2015-11-17 05:35:06 -05:00
parent ead7fd7ba3
commit bda4028c9c
9 changed files with 123 additions and 53 deletions

8
Code-Build-Process.md Normal file

@ -0,0 +1,8 @@
# Code Build Process
Code is using `gulp` to build its code base. The most important tasks are:
* `watch` - translates the TypeScript source files to JavaScript and starts a watch mode that incrementally translates TypeScript files. The incremental build is based on the `gulp-tsb` module. The TypeScript is compiled into the `out` folder.
* `test` - runs the mocha tests.
* `vscode-[platform]-min` - builds a packaged and minified version of the code for the given `[platform]`
* `minify-editor` - build a minified version of the Monaco editor

21
Code-Organization.md Normal file

@ -0,0 +1,21 @@
# Code Organization
Code consists a layered and modular `core` that can be extended using extensions. Extensions are run in a seperate process refered to as the
`extension host.` Extensions are implemented using extension API that is described in the extension documentation <<<link>>>.
# Layers
The `core` is partitioned into the following layers:
- **base** - the base provides general utilities and user interface building blocks
- **platform** - the platform defines service injection support and the base services for Code. The service injection support is described here <<<TBD>>>
- **editor** - the Monaco code editor. The editor is available as a separate downloadable component.
- **languages** - for historical reasons not all languages are provided as extensions, yet. As Code evolve we migrate more languages to towards extensions.
- **workbench** - the workbench that hosts the monaco editor provides the framework for so called viewlets like the explorer, status bar
or menu bar. The workbench leverages Electron to implement the Code desktop application.
# Target Environments
The `core` of Code is fully implemented in TypeScript. Inside each layer the code is organized by the target run-time environment. This allows us to ensure that only the run-time specific APIs are used. In the code we distinguish between the following target environment:
- **browser** - source code that requires the **browser** APIs like access to the DOM.
- **node** - source code that requires **nodejs** APIs.
- **electron** - source code that requires the **electron** APIs.
- **common** - source code that only requires basic JavaScript APIs and run in all the other target environments.

@ -1,4 +1,6 @@
<<<These are the guidelines for extensions only. They do not apply to the Code core. This information belongs to the extension doc,
not the contributing doc >>>
##Events
* We use `Event<T>` which exposes events as a function to which you subscribe by calling that function. The return value is a disposable which removes the event subscription.

17
Development-Process.md Normal file

@ -0,0 +1,17 @@
# Development Process
## Roadmap
The team has a 6 month high level road-map <<<link>>>. The road maps defines high level themes and features.
## Iterations
We then work in monthly iterations on the items on the road map. The iterations align with the calendar months. At the end of each iteration we want to have a version of Code that can be used by Code community. The work planned during an iteration is captured in the iteration plan. The feature highlights of each iteration are highlighted in the release notes.
## Inside an Iteration
We work in weekly segments:
- 1st week - reduce debt introduced in the previous iteration, address critical issues uncovered in the previous iteration, plan the next iteration
- 2nd week - work according the plan
- 3rd week - work according the plan
- 4th week - iteration end game, the teams tests the new features according a test plan, fixes bugs, and updates the documentation

16
Home.md

@ -1,21 +1,27 @@
## Welcome
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.
Welcome to the Code Wiki. These pages are primarily intended for those who wish to contribute to the 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 [homepage](http://code.visualstudio.com) and follow us on [twitter](https://twitter.com/code)!
## Project Overview
### Process
* [[Development Process]]
* [[Roadmap]]
* [[Design Goals]]
* [[November-Plan]]
* [[Issue Tracking Workflow]]
### Code
* [[Code-Organization]]
* [[Code-Build-Process]]
## Documentation
* [API](https://github.com/Microsoft/vscode-extensionbuilders/tree/master/docs/extensionAPI)
* [API](https://github.com/Microsoft/vscode-extensionbuilders/tree/master/docs/extensionAPI) <<<**TO DO** these docs will merge with the other docs and the extension builds doc will disappear >>>
* [Extensions](https://github.com/Microsoft/vscode-extensionbuilders/tree/master/docs/extensions)
## Contributing to VS Code
## Contributing to Code
* [[How to Contribute]]
* [[Coding Guidelines]]
* [[Coding Guidelines]] <<<**TO DO**>>>
* [Running Tests](https://github.com/Microsoft/vscode/blob/master/test/README.md)

@ -1,10 +1,10 @@
There are three great ways to contribute to the VS Code project: logging bugs, submitting pull requests, and creating suggestions.
There are three great ways to contribute to the Code project: logging bugs, submitting pull requests, and creating suggestions.
## 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 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
* Version of Code
* Description of what you expect to happen
* Animated GIFs
* Errors in the Dev Tools (Help | Toggle Developer Tools)

@ -6,13 +6,15 @@ We use Labels to track the status of suggestions or feature requests. You can ex
`[empty]`
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.
Issues that are unlabelled have not been looked at by a Code team member <<<we should be less inclusive, in eclipse we would have used
committer, which is not a fashionable term anymore. Maybe 'Code core contributor'>>>. 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 `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.
<<<other teams use a help wanted for simple to fix bugs, this has never worked for me in the past so we should not do it >>>
`Suggestion`
@ -38,4 +40,4 @@ We consider this issue to not be a bug, but rather a design change or feature of
Issues that are not bugs or suggestions will be labelled appropriately (`Question`, `By Design`, `External`) and closed.
Please use [Stack Overflow](http://go.microsoft.com/fwlink/?LinkID=536384) for VS Code questions.
Please use [Stack Overflow](http://go.microsoft.com/fwlink/?LinkID=536384) for Code questions.

24
November-Plan.md Normal file

@ -0,0 +1,24 @@
# November Plan
## Theme
Get ready for `Connect()` and then recover from `Connect`
## Items
Before `Connect()` - finish:
* Improve Theming support, make themes work better with the tokens we produce
* Support to import TextMate snippets
* Adopt latest version of Electron
* Make Code Open Source on github
* Provide beta version of the extension API
* Make the gallery available
* Initial version of the extension documentation
After `Connect()` - decompress:
* Support the extender community
* React to feedback from the community
* Tune our development workflows
* Build extensions
* Improve the documentation
* Revive smart editing features that were lost during the
* Explore integrating the Salsa component from the TypeScript team

@ -1,46 +1,36 @@
# 0.11.0
## Schedule
# Roadmap
| Task | Dates |
| ------------------------- | --------------- |
| Planning | Nov 19 |
| Development | Nov 24 - Dec 17 |
| End Game | Dec 07 - Dec 10 |
| Insiders drop | Dec 10 |
| Release | Dec 17 |
This document outlines the 6 month roadmap.
## 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 |
| ------------------------- | ------------- |
| Development | Oct 5 - Nov 6 |
| Insiders drop | Nov 9 |
| Last build before Connect | Nov 16 |
| Connect event | Nov 18, 19 |
### Goals
* React to early extension feedback, expand API
* Get ready for open sourcing VS Code
### Key Initiatives
* Customization
* API
* Extension Points
* Gallery
* Development Environment
* Fill the Gallery
* SDK
* Language Service Improvements
* Telemetry for Extensions
* Engineering Improvements
* Theme: Getting to General Availability
* Accessability
* Globalization
* Stable APIs
* Performance
* Theme: Highly demanded features
* Code folding
* editor config - promote the extension to a core extension
* Global search/replace
* VIM key bindings
* Git improvements (manage remotes, .git in parent folder of workspace)
* Theme: Deepen language support
* General
* Improve managing many errors in the workspace
* Improve adding a new language to Code
* Provide a notion of a test case failure
* JavaScript
* adopt the Salsa <link> component to support mixed JS/TS development (collaboration with the TS team).
* improve JSX support (Salsa enables deeper support)
* TypeScript
* track and contribute to TypeScript
* C#
* debugging support (collaboration witht the coreCLR team)
* track and contribute to OmniSharp
* Debt: migrate _legacy_ languages into extensions
* Theme: Extensibility
* Address gaps in the API based on feedback from extenders
* Simplify the consumption of many extensions
* Address gaps in the gallery support based on feedback