You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just came across this wiki page for the official vscode repository. The process at the moment sounds more implicit than explicit, perhaps referencing this or a modified decision making tree would make it clearer for contributors and persons planning milestones and releases. Of course, the numerical criteria such as 'up votes' would need to be scaled to fit the repo.
Citation from the mentioned wiki page:
Here are the criteria we use to make the decision about closing a feature request:
Does the functionality described in the feature request have any reasonable chance to be implemented in the next 24 months? 24 months is longer than our [roadmap](https://github.com/Microsoft/vscode/wiki/Roadmap) which outlines the next 6-12 months. Thus, there is some crystal ball reading on our part, and we'll most likely keep more feature requests open than what we can accomplish in 24 months.
Has the community at large expressed interest in this functionality? I.e. has it gathered more than 20 up-votes or more than 20 comments? This criterion alone covers more than 650 of the 2850 open feature requests as of right now, October 9th, 2019.
Do we think the feature request is bold and forward looking and would we like to see it be tackled at some point even if it's further out than 24 months? (Clearly, this one is the most subjective criterion.)
If the answer to any of the three questions is yes, then we ask about affordability:
Can our team afford to implement the feature? I.e. are the costs to implement the functionality reasonable compared to the size of our team?
The text was updated successfully, but these errors were encountered:
Just came across this wiki page for the official vscode repository. The process at the moment sounds more implicit than explicit, perhaps referencing this or a modified decision making tree would make it clearer for contributors and persons planning milestones and releases. Of course, the numerical criteria such as 'up votes' would need to be scaled to fit the repo.
Citation from the mentioned wiki page:
The text was updated successfully, but these errors were encountered: