github/msft-calculator
1
0
Fork 0
mirror of https://github.com/Microsoft/calculator.git synced 2025-08-22 06:13:14 -07:00
Code Issues Projects Releases Packages Wiki Activity Actions

Align internal pitch template, feature request template, and new feature documentation

Browse source
This commit is contained in:
Matt Cooley 2019-03-05 10:04:13 -08:00
commit eeae8a6955
2 changed files with 27 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

28
.github/ISSUE_TEMPLATE/feature_request.md vendored
View file

@ -16,23 +16,18 @@ Hub instead: https://insider.windows.com/en-us/fb/?contextid=130
-->
**Problem Statement**
<!-- What problem are we trying to solve? Who’s the customer? 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? -->
<!-- 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 -->
<!-- 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 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? -->
<!-- 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
@ -40,4 +35,9 @@ don’t do this work? What is the risk if we do? -->
**Non-Goals**
<!-- Things we are explicitly not doing or supporting or that are out of scope, including reasons
why. -->
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. -->

26
docs/NewFeatureProcess.md
View file

@ -22,24 +22,24 @@ especially to new features and major visual changes.
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 customer? Is there a
* **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.
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.
The feature pitch may also include a low-fidelity concept which will be refined during the
pre-production process.
The low-fidelity concept should be kept simple at this stage and refined during the pre-production
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.