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 name: Bug report
about: Create a report to help us improve about: Report a problem with Calculator
title: '' title: ''
labels: '' labels: ''
assignees: '' assignees: ''

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

@ -1,23 +1,43 @@
--- ---
name: Feature request name: Feature request
about: Suggest an idea for this project about: Propose a new feature in the app
title: '' title: ''
labels: '' labels: ''
assignees: '' 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.** See https://github.com/Microsoft/calculator/blob/master/docs/NewFeatureProcess.md for
<!--A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]--> 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** **Problem Statement**
<!--A clear and concise description of any alternative solutions or features you've considered.--> <!-- 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** **Evidence or User Insights**
<!--Add any other context or screenshots about the feature request here.--> <!-- 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 # New feature process
## When should I follow this process? ## Where do I submit my idea for a new feature?
You need to follow this process for any change which "users will notice". This applies especially The easiest way to submit new feature requests is through [Feedback Hub](https://insider.windows.com/en-us/fb/?contextid=130).
to new features and major visual changes. 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 But using Feedback Hub is not required&mdash;_you_ can create feature pitches too! This document
development tools. To contribute these changes, discuss the issue with the team and then submit a explains the elements of a good pitch and how we'll guide features from a pitch to a finished
pull request. 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 ## Do I need to follow this process? Can I just start coding and submit a PR?
New features are submitted in Feedback Hub. In Feedback Hub you can upvote existing feedback or You *do not* need to follow this process for bug fixes, performance improvements, or changes to the
submit your own. We also encourage discussion on open issues in Feedback Hub and in GitHub. 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 You *do* need to follow this process for any change which "users will notice". This applies
New features must have a sponsor from the Microsoft product team. We can only work on a few ideas especially to new features and major visual changes.
at a time, so some good feature ideas might remain open but unassigned to a sponsor.
## Step 3: Scoping and feature pitch ## Step 1: Feature pitch
Once we've decided to sponsor a feature, a member of the Microsoft team will write a The feature pitch concisely describes a point of view on the problem the new feature should solve.
*feature pitch*. The feature pitch concisely describes our point of view on the problem and will It will typically include these sections:
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 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? 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, * **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 other GitHub issues, other anecdotes from listening to customers in person or online, request
person, user research, market or competitive research 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 * **Proposal**: How will the solution/feature help us solve the problem? How will it meet the
solution/feature meet the customer’s needs? How will the solution/feature improve the metrics? target audience’s needs? If there are business goals or metrics, how does this improve them?
Who’s the target audience? * **Goals**: What you want to accomplish with this feature. Typical examples include “User Can
* **Risks**: This section may not be necessary if covered by the problem statement. What is the *perform some task*”
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*”
* **Non-Goals**: Things we are explicitly not doing or supporting or that are out of scope, * **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 The low-fidelity concept should be kept simple at this stage and refined during the pre-production
prototyping process. 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 ## Step 2: Pre-production
After the goals are written, we think of a variety of ways to address these goals and build In the pre-production phase, we experiment with a variety of ways to address the goals described in
*prototypes* to try them out. We welcome community participation in this process. 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 We welcome community participation in the pre-production process. The GitHub issue will be the
spending too much time making the code robust or maintainable) can be a fast and effective way to primary place to share progress updates.
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.
An important part of the prototyping process is sharing our work along the way, getting feedback, The best ideas often come from trying many ideas during the pre-production phase. To enable rapid
and iterating on the design. Drawings, links to code, and other work-in-progress can be added to experimentation, we encourage developing and sharing rough ideas&mdash;maybe even with pencil and
the wiki for this project. Progress updates will be posted in the issues section. 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 ### Spec review
with our product roadmap. If this happens, we'll document what we learned and close the issue.
## Step 5: Prototype review
Once there is a high-fidelity design which addresses the goals described in the original pitch, the 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 Microsoft product team will review the prototype and ensure all items on this checklist are
addressed: addressed:
@ -75,8 +74,8 @@ addressed:
- [ ] Is it technically feasible to build this feature? Take a look at the "before committing" - [ ] 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. checklist below and identify any issues which are likely to be blockers.
## Step 6: Implementation ## Step 3: Production
A feature can be implemented by the original proposer, the Microsoft team sponsor, or by other 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 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 in the issue comments if you're actively working on a feature so we can ensure it's assigned to
you. 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 be more work required to make the solution robust. Once the code is ready, you can begin
[submitting pull requests](../CONTRIBUTING.md). [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 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. 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) [Fiddler](http://docs.telerik.com/fiddler/knowledgebase/fiddlerscript/perftesting)
can be used to simulate slow or failed requests. 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 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. sure the final implementation is ready to [release to Windows customers](Roadmap.md#Releases).
## 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).