同步操作将从 Jerry/calculator 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
The easiest way to submit new feature requests is through Feedback Hub. 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.
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 shows all the features we're working on and where they're at in the process.
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 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.
The feature pitch concisely describes a point of view on the problem the new feature should solve. It will typically include these sections:
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.
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.
We welcome community participation in the pre-production process. The GitHub issue will be the primary place to share progress updates.
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.
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:
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.
You might be able to reuse code written during the prototype process, although there will typically be more work required to make the solution robust. Once the code is ready, you can begin submitting pull requests.
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.
New features often need a more thorough technical review than bug fixes. When reviewing code for new features, the Microsoft team considers at least these items:
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.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。