[2/3] incubator-weex-site git commit: Updating Development Process document

[ha...@apache.org]

Updating Development Process document

The document has been updated for better understand and fixing
grammatical errors.


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/3f968a69
Tree: http://git-wip-us.apache.org/repos/asf/incubator-weex-site/tree/3f968a69
Diff: http://git-wip-us.apache.org/repos/asf/incubator-weex-site/diff/3f968a69

Branch: refs/heads/master
Commit: 3f968a694e816501e0bf8dca205777ec790beef9
Parents: d58a6ac
Author: Varun Sobti <va...@paytm.com>
Authored: Wed May 23 13:08:02 2018 +0800
Committer: Varun Sobti <va...@paytm.com>
Committed: Wed May 23 13:08:02 2018 +0800

----------------------------------------------------------------------
 source/development-process.md | 48 +++++++++++++++++++++-----------------
 1 file changed, 26 insertions(+), 22 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-weex-site/blob/3f968a69/source/development-process.md
----------------------------------------------------------------------
diff --git a/source/development-process.md b/source/development-process.md
index ed01d01..54255e1 100644
--- a/source/development-process.md
+++ b/source/development-process.md
@@ -7,25 +7,25 @@ version: 2.1
 
 # Development Process
 
-This document describes how to contribute changes to the Weex source code. Below are the recommended steps.
+Contributions are always welcome, but it is very important to understand the development process to make contributing simpler. This document will help you understand how to contribute changes to the Weex source code. Below are the recommended steps.
 
 ## 1. Choose or Create a JIRA issue
 
-Generally, Weex uses [JIRA Issue](https://issues.apache.org/jira/projects/WEEX) to track all types of code changes and not just bug fixes, and uses Github pull requests to manage the review and merge of specific code changes. That is, JIRAs are used to describe *what* should be fixed or changed, and high-level approaches, and pull requests describe *how* to implement that change in the project’s source code.  
+Weex uses [JIRA](https://issues.apache.org/jira/projects/WEEX) to track all types of code changes and not just bug fixes. A JIRA ticket should be used to describe *what* should be fixed or modified and the high-level approach of *how* it will be fixed. We use Github pull requests to manage the review and merge specific code changes. Pull Requests describe *how* to implement that change in the project’s source code.  
 
-Be sure to search the issues before creating new ones to avoid duplication. If your change may be controversial, you may want to create a discussion in the [weex-dev](mailto:dev@weex.incubator.apache.org) mailing list.
+If you would like to create a new issue on JIRA, be sure to search the existing issues and see if someone has already reported the same. It helps in avoiding duplication. If your change may be controversial, you may want to create a discussion in the [weex-dev](mailto:dev@weex.incubator.apache.org) mailing list.
 
-**Every pull request should correspond to a issue in JIRA.**
+**Every pull request should correspond to an issue in JIRA.**
 
 ## 2. Develop Your Changes
 
-1. [Fork](https://help.github.com/articles/fork-a-repo/) the Github repository at [https://github.com/apache/incubator-weex](https://github.com/apache/incubator-weex) if you haven’t already. 
+1. [Fork](https://help.github.com/articles/fork-a-repo/) the Github repository at [https://github.com/apache/incubator-weex](https://github.com/apache/incubator-weex). 
 
-2. Clone your fork, create a new branch to push your commits to.
+2. Clone the forked repository and create a new branch from `master` to push your commits to.
 
-3. Develop your feature or bug fix. Make sure your changes meet the [code style guidelines](/development-process.html#code-style-guidelines).
+3. Develop your feature or bug fix in your new branch. Make sure your code meets the [style guidelines](/development-process.html#code-style-guidelines).
 
-4. Copy and paste this to the top of your new file(s):
+4. Add the below mentioned copyright notice to the top of any new file(s) you've added.
 
    ```javascript
    /*
@@ -48,26 +48,28 @@ Be sure to search the issues before creating new ones to avoid duplication. If y
     */
    ```
 
-5. Documentation and tests should be added or referenced if they need to be added or updated as part of the change.
+5. Documentation and tests should be added or referenced if they need to be added or updated as part of the change. Make sure to test your changes thoroughly.
 
-6. Commit to your branch following [commit guidelines](/development-process.html#commit-guidelines).
+6. Commit all the changes to your branch. [Commit Guidelines](/development-process.html#commit-guidelines) must be followed for better understanding.
 
 ## 3. Create a Pull Request
 
-[Open a pull request](https://help.github.com/articles/using-pull-requests/) against the `master` branch of `apache/incubator-weex`. Make sure it meets these guidelines:
+[Open a pull request](https://help.github.com/articles/using-pull-requests/) against the `master` branch of `apache/incubator-weex`. Make sure following guidelines are considered when creating a pull request.
 
-1. One pull request for one issue
-2. The PR title should be of the form `[WEEX-xxxx][COMPONENT] Summary`, where `xxxx` is the relevant JIRA number, `COMPONENT` is one of the PR categories(android, iOS, jsfm, web, doc, website, example, test, other) and Title may be the JIRA’s title or a more specific title describing the PR itself.
-3. If the pull request is still a work in progress, and so is not ready to be merged, but needs to be pushed to Github to facilitate review, then add `[WIP]` after the component.
+1. There should be one pull request for one issue.
+2. The PR title should be of the form `[WEEX-xxxx][COMPONENT] Summary` where `xxxx` is the relevant JIRA number and `COMPONENT` is one of the mentioned PR categories (android, iOS, jsfm, web, doc, website, example, test, other). `Summary` can be same as JIRA’s title or can also be a more specific title describing the PR itself.
+3. If the pull request is still a work in progress but needs to be pushed to Github to facilitate review, then add `[WIP]` after the component. This also means that the PR is not ready to be merged.
+
+**It is easier to review small pull requests and those are more likely to get merged. Prefer to split the PR if it includes changes for more than one thing.**
 
 ## Code Style Guidelines 
 
 ### Objective-C
 
-- Tabs for indentation(not spaces)
+- Tabs should be used for indentation. Please do not use spaces.
 - `*` operator goes with the variable name (e.g. Type *variable;)
-- Function definitions: place each brace on its own line.
-- Other braces: place the open brace on the line preceding the code block; place the close brace on its own line.
+- For function definitions, place each brace on its own line.
+- For all the other braces, place the open brace on the line preceding the code block and place the close brace on its own line.
 - Use `#pragma marks` to categorize methods into functional groupings and protocol implementations
 - Follow other guidelines on [GitHub Objective-C Style Guide](https://github.com/github/objective-c-style-guide)
 
@@ -78,24 +80,26 @@ Be sure to search the issues before creating new ones to avoid duplication. If y
 
 ## Commit Guidelines 
 
-Use the following form to write commit descriptions:
+Following template should be used to write commit descriptions.
 
 ```markdown
 Summary of change, same as PR title: `[WEEX-xxxx][COMPONENT] Summary`
 
-Longer description of change addressing as appropriate: why the change
-is made,context if it is part of many changes, description of previous 
+Longer description of change addressing the following: Why the change
+is made, Context if it is part of many other changes, Description of previous 
 behavior and newly introduced differences, etc.
 
 Long lines should be wrapped to 80 columns for easier log message 
-viewing interminals.
+viewing in terminals.
 
 Bug: 123456
 ```
 
 A short subject and a blank line after the subject are crucial. Use the bug number from the JIRA issue.
 
-Some good thoughts on how to write good git commit messages can be found [here](https://chris.beams.io/posts/git-commit/).
+Some good thoughts on how to write better git commit messages can be found [here](https://chris.beams.io/posts/git-commit/).
 
+## License
+By contributing to Weex, you agree that your contributions will be licensed under its Apache License, Version 2.0.