github/msft-calculator
1
0
Fork 0
mirror of https://github.com/Microsoft/calculator.git synced 2025-08-22 14:13:30 -07:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update CONTRIBUTING.md

Browse source
This commit is contained in:
Dave Grochocki 2019-04-02 18:04:17 -07:00 • committed by GitHub
commit 87dfe2a69c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

40
CONTRIBUTING.md
View file

@ -17,21 +17,32 @@ all community interactions must abide by the [Code of Conduct](CODE_OF_CONDUCT.m
## Finding issues you can help with ## Finding issues you can help with
Looking for something to work on? Looking for something to work on?
[Issues marked *good first issue*](https://github.com/Microsoft/calculator/labels/good%20first%20issue) Issues marked [``good first issue``](https://github.com/Microsoft/calculator/labels/good%20first%20issue)
are a good place to start. are a good place to start.
You can also check [the *help wanted* tag](https://github.com/Microsoft/calculator/labels/help%20wanted) You can also check the [``help wanted``](https://github.com/Microsoft/calculator/labels/help%20wanted) tag to find other issues to help with. If you're interested in working on a fix, leave a comment to let everyone know and to help avoid duplicated effort from others.
to find other issues to help with.
## Contributions we accept ## Contributions we accept
We welcome your contributions to the Calculator project, especially to fix bugs and to make We welcome your contributions to the Calculator project, especially to fix bugs and to make
improvements which address the top issues reported by Calculator users. improvements which address the top issues reported by Calculator users. Some general guidelines:
We have a high bar for new features and changes to the user experience. We prefer to evaluate * **DO** create one pull request per Issue, and ensure that the Issue is linked in the pull request.
*prototypes* to ensure that the design meets users' needs before we start discussing implementation * **DO** follow our [Coding and Style](#style-guidelines) guidelines, and keep code changes as small as possible.
details and reviewing code. We follow a [user-centered process for developing features](docs/NewFeatureProcess.md). * **DO** include corresponding tests whenever possible.
New features need sponsorship from the Calculator team, but we welcome community contributions at * **DO** check for additional occurrences of the same problem in other parts of the codebase before submitting your PR.
many stages of the process. * **DO** [link the issue](https://github.com/blog/957-introducing-issue-mentions) you are addressing in the pull request.
* **DO** write a good description for your pull request. More detail is better. Describe *why* the change is being made and *why* you have chosen a particular solution. Describe any manual testing you performed to validate your change.
* **DO NOT** submit submit a PR unless it is linked to an Issue marked [``triage approved``](https://github.com/Microsoft/calculator/issues?q=is%3Aissue+is%3Aopen+label%3A%22Triage%3A+Approved%22). This enables us to have a discussion on the idea before anyone invests time in an implementation.
* **DO NOT** merge multiple changes into one PR unless they have the same root cause.
* **DO NOT** submit pure formatting/typo changes to code that has not been modified otherwise.
We follow a [user-centered process for developing features](docs/NewFeatureProcess.md). New features
need sponsorship from the Calculator team, but we welcome community contributions at many stages of
the process.
> Submitting a pull request for an approved Issue is not a guarantee it will be approved.
> The change must meet our high bar for code quality, architecture, and performance, as well as
> [other requirements](#docs/NewFeatureProcess.md#technical-review).
## Making changes to the code ## Making changes to the code
@ -61,16 +72,7 @@ to group your changes into a small number of commits which we can review one at
When completing a pull request, we will generally squash your changes into a single commit. Please When completing a pull request, we will generally squash your changes into a single commit. Please
let us know if your pull request needs to be merged as separate commits. let us know if your pull request needs to be merged as separate commits.
## Submitting a pull request and participating in code review ## Review Process
Writing a good description for your pull request is crucial to help reviewers and future
maintainers understand your change. More detail is better.
- [Link the issue you're addressing in the pull request](https://github.com/blog/957-introducing-issue-mentions).
- Describe *why* the change is being made and *why* you've chosen a particular solution.
- Describe any manual testing you performed to validate your change.
Please submit one pull request per issue. Large pull requests which have unrelated changes can be
difficult to review.
After submitting a pull request, members of the calculator team will review your code. We will After submitting a pull request, members of the calculator team will review your code. We will
assign the request to an appropriate reviewer within two days. Any member of the community may assign the request to an appropriate reviewer within two days. Any member of the community may
participate in the review, but at least one member of the Calculator team will ultimately approve participate in the review, but at least one member of the Calculator team will ultimately approve