You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@weex.apache.org by ha...@apache.org on 2017/11/06 03:07:18 UTC
[7/7] incubator-weex-site git commit: [WEEX-86][doc] fix some grammar
& expression issues in bug-report-guidelines.md
[WEEX-86][doc] fix some grammar & expression issues in bug-report-guidelines.md
Project: http://git-wip-us.apache.org/repos/asf/incubator-weex-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-weex-site/commit/654ee826
Tree: http://git-wip-us.apache.org/repos/asf/incubator-weex-site/tree/654ee826
Diff: http://git-wip-us.apache.org/repos/asf/incubator-weex-site/diff/654ee826
Branch: refs/heads/master
Commit: 654ee82661c4e8baaafb41ed74c315be9d76e610
Parents: 219da04
Author: yinfeng <cx...@apache.org>
Authored: Thu Oct 26 13:59:25 2017 +0800
Committer: Hanks <zh...@gmail.com>
Committed: Mon Nov 6 11:04:02 2017 +0800
----------------------------------------------------------------------
source/bug-report-guidelines.md | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-weex-site/blob/654ee826/source/bug-report-guidelines.md
----------------------------------------------------------------------
diff --git a/source/bug-report-guidelines.md b/source/bug-report-guidelines.md
index 64bad01..795af12 100644
--- a/source/bug-report-guidelines.md
+++ b/source/bug-report-guidelines.md
@@ -7,12 +7,12 @@ version: 2.1
# Bug Report Guidelines
-This document describes how to write a good Weex bug report. Good bug reports help developers decide an appropriate priority and severity for a bug, and increase the chance that a bug will be fixed quickly. The more specific information you can provide, the better.
+This document describes how to write a good Weex bug report. Good bug reports help developers classify the priority and severity of a bug properly, which helps the bug get fixed as soon as possible. The more specific information you provide, the better your bug gets understood.
## Bug Report General Principles
-- Avoid duplicates: Search before you file!
-- Always test the latest available version.
+- Avoid duplicates: Search before you file a new one!
+- Always test the latest available version before submitting a bug.
- One bug per report.
- State useful facts, not opinions or complaints.
@@ -30,13 +30,13 @@ A good Example: `List Crashes when deleting a header`
### Environment
-**Weex Version**: Please tell the version of WeexSDK or Weex Playground or weex-toolkit you were using when the bug occurred
+**Weex Version**: Please identify the version of WeexSDK or Weex Playground or weex-toolkit you were using when the bug occurred
-**Device environment**: Please tell the device model, platform and OS version that your bug occurred on. e.g. , iPhone 6, iOS 10.3.
+**Device environment**: Please identify the device model, platform and OS version. e.g. , iPhone 6, iOS 10.3.
### Overview/Description
-The overview or description of a bug report is to explain the bug to the developer, including:
+The overview or description of a bug report is to explain the bug in detail, including:
- Justifications of why this is a bug
- [dotwe](http://dotwe.org/vue/) demo that can reproduce the bug
@@ -46,7 +46,7 @@ The overview or description of a bug report is to explain the bug to the develop
### Steps to Reproduce
-The goal of reproducible steps is to teach developer to recreate the bug on his own system, such as:
+The aim to provide the reproducible steps is to enable developers to reproduce the bug in their own environment. Here's an example:
*Step 1: Load the demo using Weex Playground*
@@ -56,7 +56,7 @@ The goal of reproducible steps is to teach developer to recreate the bug on his
### Test Results
-The test results, including *Expected Result* and *Actual Result*, will show the developer what's wrong. *Expected Result* describes what should have happened, and *Actual Result* describes what actually happened.
+The test results, including *Expected Result* and *Actual Result*, will tell developers what's wrong. *Expected Result* describes what should have happened, and *Actual Result* describes what actually happened.
## Reference