enhance documentation around contributing to electron (#11887)
* add issues document * add documentation coding style to doc * copyediting * replace `nodejs/node` with `electron/electron` * fix commasplice * fix two most important... s/is/are/ * omit unnecessary words * add pull requests doc * copyediting * add general code style to styleguide * updates to CONTRIBUTING.md * copyediting * mark shell blocks as ```sh * mitigate phrase duplication e.g. 'best practice' * lots of opinionated changes to omit unnecessary words * fix numbering & re-apply changes that I overwrote
This commit is contained in:
parent
31e0bc02ba
commit
533dfc42a8
4 changed files with 397 additions and 62 deletions
109
docs/development/issues.md
Normal file
109
docs/development/issues.md
Normal file
|
@ -0,0 +1,109 @@
|
|||
# Issues In Electron
|
||||
|
||||
# Issues
|
||||
|
||||
* [How to Contribute in Issues](#how-to-contribute-in-issues)
|
||||
* [Asking for General Help](#asking-for-general-help)
|
||||
* [Submitting a Bug Report](#submitting-a-bug-report)
|
||||
* [Triaging a Bug Report](#triaging-a-bug-report)
|
||||
* [Resolving a Bug Report](#resolving-a-bug-report)
|
||||
|
||||
## How to Contribute in Issues
|
||||
|
||||
For any issue, there are fundamentally three ways an individual can
|
||||
contribute:
|
||||
|
||||
1. By opening the issue for discussion: If you believe that you have found
|
||||
a new bug in Electron, you should report it by creating a new issue in
|
||||
the `electron/electron` issue tracker.
|
||||
2. By helping to triage the issue: You can do this either by providing
|
||||
assistive details (a reproducible test case that demonstrates a bug) or by
|
||||
providing suggestions to address the issue.
|
||||
3. By helping to resolve the issue: This can be done by demonstrating
|
||||
that the issue is not a bug or is fixed; but more often, by opening
|
||||
a pull request that changes the source in `electron/electron` in a
|
||||
concrete and reviewable manner.
|
||||
|
||||
## Asking for General Help
|
||||
|
||||
Because the level of activity in the `electron/electron` repository is
|
||||
so high, questions or requests for general help using Electron should
|
||||
be directed at the [community slack channel](https://atomio.slack.com)
|
||||
or the [forum](https://discuss.atom.io/c/electron).
|
||||
|
||||
## Submitting a Bug Report
|
||||
|
||||
When opening a new issue in the `electron/electron` issue tracker, users
|
||||
will be presented with a template that should be filled in.
|
||||
|
||||
```markdown
|
||||
<!--
|
||||
Thanks for opening an issue! A few things to keep in mind:
|
||||
|
||||
- The issue tracker is only for bugs and feature requests.
|
||||
- Before reporting a bug, please try reproducing your issue against
|
||||
the latest version of Electron.
|
||||
- If you need general advice, join our Slack: http://atom-slack.herokuapp.com
|
||||
-->
|
||||
|
||||
* Electron version:
|
||||
* Operating system:
|
||||
|
||||
### Expected behavior
|
||||
|
||||
<!-- What do you think should happen? -->
|
||||
|
||||
### Actual behavior
|
||||
|
||||
<!-- What actually happens? -->
|
||||
|
||||
### How to reproduce
|
||||
|
||||
<!--
|
||||
|
||||
Your best chance of getting this bug looked at quickly is to provide a REPOSITORY that can be cloned and run.
|
||||
|
||||
You can fork https://github.com/electron/electron-quick-start and include a link to the branch with your changes.
|
||||
|
||||
If you provide a URL, please list the commands required to clone/setup/run your repo e.g.
|
||||
|
||||
$ git clone $YOUR_URL -b $BRANCH
|
||||
$ npm install
|
||||
$ npm start || electron .
|
||||
|
||||
-->
|
||||
```
|
||||
|
||||
If you believe that you have found a bug in Electron, please fill out this
|
||||
form to the best of your ability.
|
||||
|
||||
The two most important pieces of information needed to evaluate the report are
|
||||
a description of the bug and a simple test case to recreate it. It easier to fix
|
||||
a bug if it can be reproduced.
|
||||
|
||||
See [How to create a Minimal, Complete, and Verifiable example](https://stackoverflow.com/help/mcve).
|
||||
|
||||
## Triaging a Bug Report
|
||||
|
||||
It's common for open issues to involve discussion. Some contributors may
|
||||
have differing opinions, including whether the behavior is a bug or feature.
|
||||
This discussion is part of the process and should be kept focused, helpful,
|
||||
and professional.
|
||||
|
||||
Terse responses that provide neither additional context nor supporting detail
|
||||
are not helpful or professional. To many, such responses are annoying and
|
||||
unfriendly.
|
||||
|
||||
Contributors are encouraged to solve issues collaboratively and help one
|
||||
another make progress. If encounter an issue that you feel is invalid, or
|
||||
which contains incorrect information, explain *why* you feel that way with
|
||||
additional supporting context, and be willing to be convinced that you may
|
||||
be wrong. By doing so, we can often reach the correct outcome faster.
|
||||
|
||||
## Resolving a Bug Report
|
||||
|
||||
Most issues are resolved by opening a pull request. The process for opening and
|
||||
reviewing a pull request is similar to that of opening and triaging issues, but
|
||||
carries with it a necessary review and approval workflow that ensures that the
|
||||
proposed changes meet the minimal quality and functional guidelines of the
|
||||
Electron project.
|
Loading…
Add table
Add a link
Reference in a new issue