Documentation: revise the new feature process (microsoft#82)

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,6 +1,6 @@
 ---
 name: Bug report
-about: Create a report to help us improve
+about: Report a problem with Calculator
 title: ''
 labels: ''
 assignees: ''

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,23 +1,43 @@
 ---
 name: Feature request
-about: Suggest an idea for this project
+about: Propose a new feature in the app
 title: ''
 labels: ''
 assignees: ''
 
 ---
 
-**Please describe your feature request.**
-<!--For more information see https://github.com/Microsoft/calculator/blob/master/docs/NewFeatureProcess.md -->
+<!--
 
-**Is your feature request related to a problem? Please describe.**
-<!--A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]-->
+See https://github.com/Microsoft/calculator/blob/master/docs/NewFeatureProcess.md for
+suggestions on how to write a good feature pitch. Just want to submit an idea quickly? Try Feedback
+Hub instead: https://insider.windows.com/en-us/fb/?contextid=130
 
-**Describe the solution you'd like**
-<!--A clear and concise description of what you want to happen.-->
+-->
 
-**Describe alternatives you've considered**
-<!--A clear and concise description of any alternative solutions or features you've considered.-->
+**Problem Statement**
+<!-- What problem are we trying to solve? Who’s the target audience? Is there a customer need or
+pain point we need to remedy? Is there a business goal or metric we are trying to improve? Do we
+have a hypothesis we want to prove or disprove? -->
 
-**Additional context**
-<!--Add any other context or screenshots about the feature request here.-->
+**Evidence or User Insights**
+<!-- Why should we do this? Potential sources of data: Feedback Hub, other GitHub issues, other
+anecdotes from listening to customers in person or online, request from another team, telemetry
+data, user research, market or competitive research -->
+
+**Proposal**
+<!-- How will the solution/feature help us solve the problem? How will it meet the target
+audience’s needs? If there are business goals or metrics, how does this improve them? -->
+
+**Goals**
+<!-- What you want to accomplish with this feature. Typical examples include
+“User Can *perform some task*” -->
+
+**Non-Goals**
+<!-- Things we are explicitly not doing or supporting or that are out of scope, including reasons
+why. -->
+
+**Low-Fidelity Concept**
+<!-- Show as much of the experience as needed to explain the idea. This can be as simple as a
+napkin drawing but can also be a code prototype, a PowerPoint walkthrough, or a design
+comp. -->

docs/NewFeatureProcess.md

@@ -1,65 +1,64 @@
 # New feature process
 
-## When should I follow this process?
-You need to follow this process for any change which "users will notice". This applies especially
-to new features and major visual changes.
-
-You do not need to follow this process for bug fixes, performance improvements, or changes to the
-development tools. To contribute these changes, discuss the issue with the team and then submit a
-pull request.
-
-## Step 1: Create an issue and discuss with the community
-New features are submitted in Feedback Hub. In Feedback Hub you can upvote existing feedback or
-submit your own. We also encourage discussion on open issues in Feedback Hub and in GitHub.
-
-## Step 2: Wait for Microsoft product team sponsorship
-New features must have a sponsor from the Microsoft product team. We can only work on a few ideas
-at a time, so some good feature ideas might remain open but unassigned to a sponsor.
-
-## Step 3: Scoping and feature pitch
-Once we've decided to sponsor a feature, a member of the Microsoft team will write a
-*feature pitch*. The feature pitch concisely describes our point of view on the problem and will
-typically include these sections:
-
-* **Problem Statement**: What problem are we trying to solve? Who’s the customer? Is there a
+## Where do I submit my idea for a new feature?
+The easiest way to submit new feature requests is through [Feedback Hub](https://insider.windows.com/en-us/fb/?contextid=130).
+In Feedback Hub, any Windows user (even if they aren't on GitHub) can upvote suggestions. The
+Calculator team reviews these suggestions regularly, and when we're ready to work on an idea we
+create [feature pitch issues here on GitHub](https://github.com/Microsoft/calculator/issues?q=is%3Aissue+is%3Aopen+project%3AMicrosoft%2Fcalculator%2F1).
+
+But using Feedback Hub is not required—_you_ can create feature pitches too! This document
+explains the elements of a good pitch and how we'll guide features from a pitch to a finished
+product. The [Feature Tracking board](https://github.com/Microsoft/calculator/projects/1) shows
+all the features we're working on and where they're at in the process.
+
+## Do I need to follow this process? Can I just start coding and submit a PR?
+You *do not* need to follow this process for bug fixes, performance improvements, or changes to the
+development tools. To contribute these changes, [discuss the proposed change in an issue](https://github.com/Microsoft/calculator/issues/new)
+and then submit a pull request.
+
+You *do* need to follow this process for any change which "users will notice". This applies
+especially to new features and major visual changes.
+
+## Step 1: Feature pitch
+The feature pitch concisely describes a point of view on the problem the new feature should solve.
+It will typically include these sections:
+
+* **Problem Statement**: What problem are we trying to solve? Who’s the target audience? Is there a
   customer need or pain point we need to remedy? Is there a business goal or metric we are trying
   to improve? Do we have a hypothesis we want to prove or disprove?
 * **Evidence or User Insights**: Why should we do this? Potential sources of data: Feedback Hub,
-  GitHub, request from another team, telemetry data, anecdotes from listening to customers in
-  person, user research, market or competitive research
-* **Proposal**: How will the solution/feature help us solve the problem? How will the
-  solution/feature meet the customer’s needs? How will the solution/feature improve the metrics?
-  Who’s the target audience?
-* **Risks**: This section may not be necessary if covered by the problem statement. What is the
-  risk if we don’t do this work? What is the risk if we do?
-* **Goals**: What you want to accomplish with this feature. Typical examples include
-  “User Can *perform some task*”
+  other GitHub issues, other anecdotes from listening to customers in person or online, request
+  from another team, telemetry data, user research, market or competitive research
+* **Proposal**: How will the solution/feature help us solve the problem? How will it meet the
+  target audience’s needs? If there are business goals or metrics, how does this improve them?
+* **Goals**: What you want to accomplish with this feature. Typical examples include “User Can
+  *perform some task*”
 * **Non-Goals**: Things we are explicitly not doing or supporting or that are out of scope,
-  including any reasoning to why.
-
-The feature pitch may also include a low-fidelity concept which will be refined during the
-prototyping process.
+  including reasons why.
+* **Low-Fidelity Concept**: Show as much of the experience as needed to explain the idea. This
+  can be as simple as a napkin drawing but can also be a code prototype, a PowerPoint walkthrough,
+  or a design comp.
 
-We will edit the issue description on GitHub to include the feature pitch.
+The low-fidelity concept should be kept simple at this stage and refined during the pre-production
+process.
 
-## Step 4: Prototyping
-After the goals are written, we think of a variety of ways to address these goals and build
-*prototypes* to try them out. We welcome community participation in this process.
+Feature pitches are submitted as issues on GitHub. We encourage discussion on open issues, and as
+discussion progresses we will edit the issue description to refine the idea.
 
-Prototypes can take many forms. For many ideas, making changes directly to the app code (without
-spending too much time making the code robust or maintainable) can be a fast and effective way to
-try out new ideas. Or you might prefer to use design software, or even pencil and paper. Work from
-low-fidelity to high-fidelity—try a few ideas for the overall approach before making your
-preferred design pixel-perfect.
+## Step 2: Pre-production
+In the pre-production phase, we experiment with a variety of ways to address the goals described in
+the feature pitch. The output of this phase is a specification which demonstrates how the feature
+will work, supported by design renderings and code prototypes as needed. Sometimes we'll learn new
+things about a feature proposal during pre-production, and we'll edit or close the original pitch.
 
-An important part of the prototyping process is sharing our work along the way, getting feedback,
-and iterating on the design. Drawings, links to code, and other work-in-progress can be added to
-the wiki for this project. Progress updates will be posted in the issues section.
+We welcome community participation in the pre-production process. The GitHub issue will be the
+primary place to share progress updates.
 
-During the investigation phase, we might discover that the idea isn't feasible or doesn't align
-with our product roadmap. If this happens, we'll document what we learned and close the issue.
+The best ideas often come from trying many ideas during the pre-production phase. To enable rapid
+experimentation, we encourage developing and sharing rough ideas—maybe even with pencil and
+paper—before making designs pixel-perfect or making code robust and maintainable.
 
-## Step 5: Prototype review
+### Spec review
 Once there is a high-fidelity design which addresses the goals described in the original pitch, the
 Microsoft product team will review the prototype and ensure all items on this checklist are
 addressed:
@@ -75,8 +74,8 @@ addressed:
 - [ ] Is it technically feasible to build this feature? Take a look at the "before committing"
   checklist below and identify any issues which are likely to be blockers.
 
-## Step 6: Implementation
-A feature can be implemented by the original proposer, the Microsoft team sponsor, or by other
+## Step 3: Production
+A feature can be implemented by the original proposer, a Microsoft team member, or by other
 community members. Code contributions and testing help are greatly appreciated. Please let us know
 in the issue comments if you're actively working on a feature so we can ensure it's assigned to
 you.
@@ -85,7 +84,7 @@ You might be able to reuse code written during the prototype process, although t
 be more work required to make the solution robust. Once the code is ready, you can begin
 [submitting pull requests](../CONTRIBUTING.md).
 
-## Step 7: Technical review
+### Technical review
 As with all changes, the code for new features will be reviewed by a member of the Microsoft team
 before being checked in to the master branch.
 
@@ -135,15 +134,6 @@ new features, the Microsoft team considers at least these items:
       [Fiddler](http://docs.telerik.com/fiddler/knowledgebase/fiddlerscript/perftesting)
       can be used to simulate slow or failed requests.
 
-## Step 8: Final product review and merge to master
+## Step 4: Final product review and merge to master
 After the technical review is complete, the product team will review the finished product to make
-sure the final implementation is ready to release to Windows customers.
-
-## Step 9: Release
-The release process is handled internally by the Microsoft team. When we release, we create a
-`servicing` branch from master. We merge changes into servicing branches only to fix severe bugs.
-
-Releases are distributed through the Microsoft Store, first to Windows Insiders and then to all
-supported Windows 10 devices once we are confident in the update's quality. We usually ship an
-update every month. After the app has been released to the Microsoft Store, it will be part of
-the next major update to Windows 10 (especially for new devices).
+sure the final implementation is ready to [release to Windows customers](Roadmap.md#Releases).