microsoft/vscode
1
0
Fork 0
mirror of https://github.com/microsoft/vscode.git synced 2025-12-10 00:27:05 -06:00
Code Issues Packages Projects Releases 177 Wiki Activity

writing more docs!

Chris Dias 2015-11-15 21:35:31 +01:00
parent 3bca4c1705
commit ead7fd7ba3
8 changed files with 69 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.vscode/settings.json vendored Normal file

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

4
Breaking-Changes.md

@ -1,8 +1,6 @@
# Breaking Changes
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 lock
down the API set.
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.
## 0.11.0

20
Contributor-License-Agreement.md

@ -1,20 +1,8 @@
#Contributor License Agreement
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.
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.
However, you don't have to do this up-front. You can simply
clone, fork, and submit your pull-request as usual.
However, 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, 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`.
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`.
Signing the CLA might sound scary but it's actually very
simple and can be done in less than a minute.
Signing the CLA might sound scary but it's actually very simple and can be done in less than a minute.

8
Home.md

@ -1,12 +1,8 @@
## 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 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.
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)!
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
* [[Roadmap]]

19
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
already and if not, all of the following are helpful so we can better reproduce the problem.
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
* 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
[[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]].
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]].
## Suggestions
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.
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.
## Discussion Etiquette
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.
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.

38
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`
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:
>`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

19
Planning-and-Triage-Process.md Normal file

@ -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.

23
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 |
| ------------------------- | ------------- |