New Feature Process

Windows Calculator follows a user-centered process for developing features. This guide explains how features progress from initial idea to finished product.

​

Overview

New features need sponsorship from the Calculator team, but we welcome community contributions at many stages of the process. The Feature Tracking board shows all the features we’re working on and their current status.

​

Where to Submit Ideas

The easiest way to submit new feature requests is through Feedback Hub.

​

Why Feedback Hub?

• Any Windows user can upvote suggestions (even without GitHub)
• The Calculator team reviews suggestions regularly
• Top ideas become feature pitch issues on GitHub

Can I create feature pitches directly on GitHub?

Yes! You don’t have to use Feedback Hub - you can create feature pitches directly on GitHub. This document explains what makes a good pitch and how features progress from pitch to finished product.

​

Step 1: Feature Pitch

Feature pitches are submitted as issues on GitHub using the Feature Request template.

​

Creating a Good Pitch

A good feature pitch includes:

• Problem statement: What user need does this address?
• Proposed solution: How would this feature work?
• User scenarios: Who would use this and how?
• Alternatives considered: What other approaches were considered?

​

Review and Approval

We review pitches regularly and will approve or close issues based on whether they broadly align with the Calculator roadmap.

• Approved pitches: Moved into Planning on the feature tracking board
• Declined pitches: Closed with explanation

​

Step 2: Planning

For most features, the output of this phase is a specification describing how the feature will work, supported by design renderings and code prototypes as needed.

​

Specification Process

• The original issue continues to track overall progress
• Spec documentation is created and iterated in the Calculator Spec repo
• Sometimes we learn new things during planning that lead to editing or closing the original pitch

Community Participation in Planning

We welcome community participation throughout planning. The best ideas often come from trying many ideas during the planning 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.Ways to contribute during planning:

• Share design mockups or prototypes
• Provide feedback on proposed specs
• Test early prototypes
• Suggest alternative approaches

​

Moving to Implementation

After spec review is completed, issues move to Implementation on the feature tracking board.

​

Step 3: Implementation

A feature can be implemented by the original submitter, a Microsoft team member, or by other community members.

​

Getting Started

1. Comment on the issue to let everyone know you’re working on it (helps avoid duplicated effort)
2. You might be able to reuse code from prototypes, but it typically needs more work to be robust
3. Follow the code style guidelines
4. Submit pull requests when ready

​

Technical Review

As with all changes, code for new features will be reviewed by a member of the Microsoft team before being checked in to the master branch.

​

Technical Review Checklist

When reviewing code for new features, the Microsoft team considers at least these items:

​

Accessibility

Accessibility Checklist

All items on the Accessibility checklist should be addressed:

• Keyboard navigation works properly
• Screen readers can access all functionality
• High contrast themes are supported
• Focus indicators are visible
• Text meets minimum size requirements
• Color is not the only means of conveying information

​

Globalization

Globalization Checklist

All items on the Globalization checklist should be addressed:

• All user-facing strings are localizable
• Layout supports right-to-left languages
• Number, date, and currency formatting respect user locale
• Text can expand for longer translations
• No hardcoded cultural assumptions

​

Platform Compatibility

• Test on the oldest supported Windows version (found in AppxManifest.xml)
• Any calls to newer APIs must be conditionally enabled
• Only supported APIs are used (verify with Windows App Certification Kit)

​

App Lifecycle

Suspend and Resume

The change should save the user’s progress if the app is suspended and resumed.Code to handle these cases should be tested in the Visual Studio debugger.What to test:

• User data is preserved when app suspends
• State is correctly restored on resume
• No data loss during suspend/resume cycle

​

Device Families

• If the change has customizations for particular device families, test on those device families
• Test with app window resized to smallest possible size

​

Visual Design

Theme and Display Testing

Test the change with:

• Light theme: Default appearance
• Dark theme: Dark mode support
• High contrast themes: All high contrast options
• Accent color: Should honor user’s preferred accent color

Ensure UI remains usable and visually correct in all themes.

​

Dependencies

New Libraries or Dependencies

If the change adds new libraries or other dependencies:If packaged with the app:

• Measure the increased size of the binaries
• Ensure size increase is justified

If not maintained by Microsoft:

• Set up a plan to monitor the upstream library
• Watch for security fixes and updates
• Evaluate long-term maintenance commitment

If open-source:

• Comply with the library’s license
• Credit third parties appropriately
• Review license compatibility

​

Performance

Startup Performance

If the change adds code to the app’s startup path, or adds new XAML elements loaded at startup:

• Run the perf tests to measure any increase in startup time
• Move work out of the startup path if possible
• Consider lazy loading for non-critical components
• Profile and optimize hot paths

​

Logging

Telemetry and Logging

If the change adds additional logging:

• All logging should use TraceLogging
• Unnecessary log events should be removed
• Configure events so they’re collected only when needed
• Don’t log sensitive user data
• Ensure logging doesn’t impact performance

​

Data Compatibility

Backward Compatibility

If the change reads user data from files or app settings:

• Verify that state saved in a previous version can be used with the new version
• Test migration from old data formats
• Handle missing or corrupted data gracefully
• Don’t break user data from older versions

​

Network Requests

Network Dependencies

If the change makes network requests:Long-term support:

• Microsoft must plan to keep these dependencies secure and functional for the lifetime of the app (possibly several years)

Reliability:

• App should be fully functional if some network requests are slow or fail
• Test with tools like Fiddler to simulate slow or failed requests
• Implement appropriate timeouts and retry logic
• Provide meaningful error messages to users

​

Step 4: Final Product Review

After the technical review is complete, the product team will review the finished product to ensure the final implementation is ready to release to Windows customers.

​

What’s Evaluated

• Feature completeness against the spec
• User experience quality
• Visual polish
• Documentation completeness
• Release readiness

​

Summary: The Feature Journey