diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index ce1e68c96..859bebaa1 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.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: '' diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index a2641fa8a..3611d4edc 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.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.** - + +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** - +--> -**Describe alternatives you've considered** - +**Problem Statement** + -**Additional context** - +**Evidence or User Insights** + + +**Proposal** + + +**Goals** + + +**Non-Goals** + + +**Low-Fidelity Concept** + \ No newline at end of file diff --git a/docs/NewFeatureProcess.md b/docs/NewFeatureProcess.md index 875bacf33..6aa2e22a9 100644 --- a/docs/NewFeatureProcess.md +++ b/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). \ No newline at end of file +sure the final implementation is ready to [release to Windows customers](Roadmap.md#Releases). \ No newline at end of file