DevWiki/calculator
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation: revise the new feature process (#82)

Browse Source
This commit is contained in:
Matt Cooley 2019-03-05 15:24:32 -08:00 committed by GitHub
parent 4c41f23ec4
commit 3698961862
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 81 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/ISSUE_TEMPLATE/bug_report.md vendored
View File

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

42
.github/ISSUE_TEMPLATE/feature_request.md vendored
View File

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

108
docs/NewFeatureProcess.md
View File

@ -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.
## 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).
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.
But using Feedback Hub is not required&mdash;_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.
## 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.
## 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.
## 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.
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 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:
## 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 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
prototyping process.
The low-fidelity concept should be kept simple at this stage and refined during the pre-production
process.
We will edit the issue description on GitHub to include the feature pitch.
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.
## 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.
## 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.
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&mdash;try a few ideas for the overall approach before making your
preferred design pixel-perfect.
We welcome community participation in the pre-production process. The GitHub issue will be the
primary place to share progress updates.
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.
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&mdash;maybe even with pencil and
paper&mdash;before making designs pixel-perfect or making code robust and maintainable.
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.
## 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).