+Lazy consensus means that Contributors may proceed with work when they have reason to believe that other Contributors in the community will agree with the direction of their work, and do not need to stop or initiate unnecessary discussion about the work. Contributors should publish their work (that is, merge proposals to master branch) in a timely manner to allow others to possibly raise issues about the work. When the Contributor is not sure there will be consensus, they should raise a proposal to the community via appropriate public communication channels(**_currently Github issues is possible way to achieve this_**)
+Silent Consent means that those who do not offer a reasoned alternative in course of the discussion implicitly agree with the proposal.
+
+
+
+### Meritocracy
+
+Responsibilities in the project (including decision making) are given to those who exhibit both the technical skill and dedication to project via their ongoing valuable contributions. Decision making happens inside the community, with more weight given to those who are more familiar with the code.
diff --git a/docs/help/Developer's-Guide.md b/docs/help/Developer's-Guide.md
new file mode 100644
index 0000000000..fe8d950e46
--- /dev/null
+++ b/docs/help/Developer's-Guide.md
@@ -0,0 +1,3 @@
+ - [Getting Started](Getting-Started.md)
+ - [Developer Tutorial](Developer-Tutorial.md)
+ - [IoT.js API Reference](../api/IoT.js-API-reference.md)
\ No newline at end of file
diff --git a/docs/help/Developer-Tutorial.md b/docs/help/Developer-Tutorial.md
new file mode 100644
index 0000000000..cb7189ff42
--- /dev/null
+++ b/docs/help/Developer-Tutorial.md
@@ -0,0 +1,161 @@
+### Getting Started with Examples
+As **IoT.js** is asynchronous and event-driven, programming style is pretty much different from traditional blocking synchronous style. This tutorial lets you know how to code with **IoT.js** mainly focused on asynchronous and event-driven style.
+
+#### Hello World
+Firstly, create a javascript file (e.g. `hello.js`) and open it. Then type as following.
+```javascript
+console.log('Hello, world!');
+```
+
+You must be familiar with the code above if you have ever worked with Javascript in web. This is exactly same way as in major web browsers.
+
+You can run it with:
+```
+$ ./iotjs hello.js
+```
+
+Then it gives:
+```
+Hello, world!
+```
+
+Pretty simple. But where did `console` come from? `console` is not defined in Global Object according to ECMAScript spec.
+
+The answer is `console` is a builtin module so it should have been `require`ed. However, `console` is a special case so we can use it directly without `require`. This is about Module System which we will cover later.
+
+#### File Reader
+To read a file, we need to import *File System* module.
+When importing a module, we use function `require`.
+*File System* module is abbreviated as `fs`. You can import it like:
+```javascript
+var fs = require('fs');
+```
+
+Then we can use APIs of `fs`. To read the whole file, use `readFile()`.
+```javascript
+fs.readFile("hello_iotjs.txt", // path
+ readFileCallback); // callback
+```
+Let's say we want to read `hello_iotjs.txt`. Just pass it as first argument.
+It may be enough for synchronous style but we must specify a callback function as last argument. `fs.readFile` does not wait for I/O to be done, it just goes on to next code. Sometime after file opening is completely done, callback will be called. This means that we must not implement `readFile` handling code on the next line, but in callback function.
+
+Take a look at the callback function for `fs.readFile` below.
+```javascript
+function readFileCallback(err, data) {
+ if (err) throw err;
+ console.log(data.toString());
+}
+```
+We can find two arguments in this function. We can think of them as the results of `fs.open`. In this case(`fs.readFile`), `err` and `data` are given. Of course, each API function has their own argument list.
+
+`err` is an `Error` object. We just throw it if an error has occurred. Otherwise we have successfully read the file content and it is stored in `data`. In this example, it only prints the file content but you can do anything you want.
+
+##### full code list
+```javascript
+var fs = require('fs');
+
+fs.readFile("hello_iotjs.txt", // path
+ readFileCallback); // callback
+
+function readFileCallback(err, data) {
+ if (err) throw err;
+ console.log(data.toString());
+}
+```
+
+#### TCP Echo Server
+`net` module provides APIs for creating servers and clients. In this tutorial, we are going to create a server only. We can connect to the server and test it with external tools(e.g. `nc`).
+
+Firstly, we need to require `net` module.
+```javascript
+var net = require('net');
+var port = 1235; // custom port number
+```
+Then create a server with `net.createServer()`. It could have some arguments
+```javascript
+var server = net.createServer();
+```
+After creating a server, make the server listen for connections.
+```javascript
+server.listen(port);
+```
+By calling `listen`, object `server` starts listening with given port. Of course `listen` is processed asynchronously but we do not have to specify a callback. What we want to do next is not necessarily done in the callback because we are just going to add some event handlers.
+
+**IoT.js** is event-driven. We can do a lot of stuff with event handlers.
+Both `Server` and `Socket` object inherits from `EventsEmitter`, so we can add event listeners for them. For servers, we probably want to add a listener for `'connection'` event which is emitted when a new connection is made. Take a look at the following.
+```javascript
+server.on('connection', function(socket) {
+ socket.on('data', function(data) {
+ socket.write("echo: " + data);
+ });
+});
+```
+In `File Reader` example, we defined callbacks outside and referred them as arguments. In this time the function is embedded as a Function Expression.
+
+When `'connection'` event is emitted, it creates a socket and we can get it from the first argument. In the same way we did for server, add a ``data`` listener for each socket which is emitted when data is received. As we are creating an echo server, what we want to do here is just send the `data` back to client. Note that to clarify this is an echoed data, `"echo: "` is prepended to it.
+
+That is all. We just implemented an echo server less than 10 lines. Actually, the server will run forever because we did not add code for closing the server. As long as the server is listening, it does not terminate even if there is no more *javascript* code to run. As this is a simple tutorial, just kill the process manually like pressing `Ctrl+C`
+
+##### full code list
+
+```javascript
+var net = require('net');
+var port = 1235;
+
+var server = net.createServer();
+server.listen(port, 5);
+server.on('connection', function(socket) {
+ socket.on('data', function(data) {
+ socket.write("echo: " + data);
+ });
+});
+```
+##### test the server
+We have created a server but not a client. Instead of implementing a client, we are going to use a unix tool `nc`.
+
+Run the server first:
+```
+$ ./iotjs echo_server.js &
+```
+
+Connect to the server with `nc`
+```
+$ nc localhost 1235
+```
+Type whatever you want to send, and the message will be echoed back.
+```
+hello, echo server!
+echo: hello, echo server!
+```
+
+### Module System
+Javascript(ECMAScript 5.1 or under) itself does not support module system. In web browsers, even though a web page loads several Javascript files, they are evaluated in the same context. To overcome this language limit, **IoT.js** supports [CommonJS](http://www.commonjs.org/) modules.
+
+We have used some of native modules through the examples above. When importing those modules, we use `require` function. Once `require`ed a module, we can use its APIs that are exported from the module. It will be covered in the section [Writing user modules](#writing-user-modules).
+
+#### Writing user modules
+When writing a module, APIs must be exposed by adding it in `exports` object. Otherwise it can be used only inside the module. Object `exports` will be returned when another module calls `require`.
+
+Let's write a sample module. Save it as `mymodule.js`
+```javascript
+exports.hello = 'Hello, IoT.js!'; // string
+exports.add = function(a, b) { // function
+ return a + b;
+}
+var local = 'local string'; // string (not exported)
+```
+Let's write another module that uses the module we just wrote. By calling `require`, we get its `exports` object. We will name it `mymodule_test.js`
+```javascript
+var mymodule = require('mymodule');
+console.log(mymodule.hello);
+console.log(mymodule.add(1, 2));
+console.log(mymodule.local);
+```
+Save two files in the same directory so **IoT.js** can automatically find `mymodule.js`. Then we are ready to go. Execute the later script then you will see:
+```
+$ ./iotjs mymodule_test.js
+Hello, IoT.js!
+3
+undefined
+```
+Note that `console.log(local)` prints `undefined`. It cannot be referred because it is not added in `exports`.
\ No newline at end of file
diff --git a/docs/Development-Process.md b/docs/help/Development-Process.md
similarity index 94%
rename from docs/Development-Process.md
rename to docs/help/Development-Process.md
index 745906860e..707b2d7628 100644
--- a/docs/Development-Process.md
+++ b/docs/help/Development-Process.md
@@ -11,7 +11,7 @@ Individual developers maintain a local copy of the IoT.js codebase using the git
### Proposals, Get Answers and Report a Bug via Github Issues
-If you have a question about IoT.js code, have trouble any documentation, would like to suggest new feature, or find a bug, [review the current IoT.js issues](https://github.com/Samsung/iotjs/issues) in GitHub, and if necessary, [create a new issue](https://github.com/Samsung/IoT.js/issues/new).
+If you have a question about IoT.js code, have trouble any documentation, would like to suggest new feature, or find a bug, [review the current IoT.js issues](https://github.com/Samsung/iotjs/issues) in GitHub, and if necessary, [create a new issue](https://github.com/Samsung/iotjs/issues/new).
**There are several labels on the Issue. Please choose proper labels on the purpose.**
* **bug**
@@ -32,11 +32,11 @@ The IoT.js Project development process is marked by the following highlights:
* The Maintainers and Reviewers evaluate the idea, give feedback, and finally approve or reject the proposal.
* The author shares the proposal with the community via **_Github issues with 'new feature request' label_**
* The community provides feedback which can be used by the author to modify their proposal and share it with the community again.
-* The above steps are repeated until the community reaches a consensus according to the [Community Guidelines](Community-Guidelines).
+* The above steps are repeated until the community reaches a consensus according to the [Community Guidelines](Community-Guidelines.md).
* After a consensus is reached, the author proceeds with the implementation and testing of the feature.
* After the author is confident their code is ready for integration:
- The author generates a patch and signs off on their code.
- - The author submits a patch according to the [Patch Submission Process](Patch-Submission-Process).
+ - The author submits a patch according to the [Patch Submission Process](Patch-Submission-Process.md).
* The Maintainers and Reviewers watch the pull request for the patch, test the code, and accept or reject the patch accordingly.
* After the code passes code review, the Maintainers and Reviewers accept the code(integrated into the master branch), which completes the development process.
* After a patch has been accepted, it remains the authoring developer's responsibility to maintain the code throughout its lifecycle, and to provide security and feature updates as needed.
@@ -56,9 +56,9 @@ The IoT.js Project development process is marked by the following highlights:
### Tips on GitHub Issues
-* Check existing [IoT.js issues](https://github.com/Samsung/IoT.js/issues) for the answer to your issue.
+* Check existing [IoT.js issues](https://github.com/Samsung/iotjs/issues) for the answer to your issue.
Duplicating an issue slows you and others. Search through open and closed issues to see if the problem you are running into has already been addressed.
-* If necessary, [open a new issue](https://github.com/Samsung/IoT.js/issues/new).
+* If necessary, [open a new issue](https://github.com/Samsung/iotjs/issues/new).
- Clearly describe the issue.
+ What did you expect to happen?
+ What actually happened instead?
diff --git a/docs/Getting-Started.md b/docs/help/Getting-Started.md
similarity index 77%
rename from docs/Getting-Started.md
rename to docs/help/Getting-Started.md
index 7fe2bc235c..bf0e4e8c55 100644
--- a/docs/Getting-Started.md
+++ b/docs/help/Getting-Started.md
@@ -7,14 +7,14 @@ IoT.js is built based on JerryScript(lightweight JavaScript engine) and libuv fo
* libuv: https://github.com/Samsung/libuv.git
### Build script
-There is a script to help you build IoT.js called "[build.py](../tools/build.py)" in source repository.
+There is a script to help you build IoT.js called "[build.py](../../tools/build.py)" in source repository.
### Supported platforms
Current supported platforms are **Linux and NuttX**
-* [Build for Linux](Build-for-Linux.md): Ubuntu 14.04 is used as a base platform.
-* [Build for NuttX](Build-for-NuttX.md)
-* [Build for Raspberry Pi 2](Build-for-RPi2.md)
+* [Build for Linux](../build/Build-for-Linux.md): Ubuntu 14.04 is used as a base platform.
+* [Build for NuttX](../build/Build-for-NuttX.md)
+* [Build for Raspberry Pi 2](../build/Build-for-RPi2.md)
##### Platforms to support
* OSX 10.10 as development host
@@ -31,7 +31,7 @@ Current supported platforms are **Linux and NuttX**
* Intel Edison
* (and your contributions including above plans)
-We will support the correct behavior of APIs for above environments. However, since IoT.js is targeting various kind IoT devices and platforms, single implementation cannot be the best practice for every environments. Therefore embedders should be in charge of optimization for their own environments. For more details on optimization, see the [Optimization Tips](Optimization-Tips.md) page.
+We will support the correct behavior of APIs for above environments. However, since IoT.js is targeting various kind IoT devices and platforms, single implementation cannot be the best practice for every environments. Therefore embedders should be in charge of optimization for their own environments. For more details on optimization, see the [Optimization Tips](../devs/Optimization-Tips.md) page.
### For Developers
@@ -76,9 +76,9 @@ build/x86_64-linux/debug/bin/iotjs tools/check_test.js -- start-from=test_consol
3. Set attributes on the test case if it needs in **attrs.js** where the directory of your test case belongs.
#### Advanced Topics
-You can refer to [Writing new IoT.js builtin module](Writing-New-Builtin-Module.md) and [Optimization Tips](Optimization-Tips.md) pages for detailed information.
+You can refer to [Writing new IoT.js builtin module](../devs/Writing-New-Builtin-Module.md) and [Optimization Tips](../devs/Optimization-Tips.md) pages for detailed information.
### When something goes wrong
-Please read the [Logging IoT.js execution](Logging-IoT.js-execution.md) page how to display and add log messages while developing.
+Please read the [Logging IoT.js execution](../devs/Logging-IoT.js-execution.md) page how to display and add log messages while developing.
-### [IoT.js API Reference](IoT.js-API-reference.md)
+### [IoT.js API Reference](../api/IoT.js-API-reference.md)
diff --git a/docs/Getting-involved.md b/docs/help/Getting-involved.md
similarity index 50%
rename from docs/Getting-involved.md
rename to docs/help/Getting-involved.md
index 4c7b2407e6..18f2d390ac 100644
--- a/docs/Getting-involved.md
+++ b/docs/help/Getting-involved.md
@@ -1,12 +1,12 @@
To contribute to the IoT.js Project (such as reporting bugs and submitting patches):
* Follow the [Development Process](Development-Process.md) and [GitHub contributor guidelines](https://guides.github.com/activities/contributing-to-open-source/).
* Add the [IoT.js DCO](IoT.js-Developer's-Certificate-of-Origin-1.0.md) signoff to each commit message during development.
-* Add the [License](License.md) if you introduce any new source code or script files
+* Add the [License](../License.md) if you introduce any new source code or script files
-### [Community Guideline](Community-Guidelines)
-### [IoT.js Developer's Certificate of Origin 1.0](IoT.js-Developer's-Certificate-of-Origin-1.0)
-### [Coding Style Guideline](Coding-Style-Guideline)
-### [Inside IoT.js](https://github.com/Samsung/iotjs/wiki/Inside%20IoT.js)
-### [Development Process](Development-Process)
-### [Patch Submission Process](Patch-Submission-Process)
-### [Governance](Governance)
\ No newline at end of file
+### [Community Guideline](Community-Guidelines.md)
+### [IoT.js Developer's Certificate of Origin 1.0](IoT.js-Developer's-Certificate-of-Origin-1.0.md)
+### [Coding Style Guideline](Coding-Style-Guideline.md)
+### [Inside IoT.js](../devs/Inside-IoT.js.md)
+### [Development Process](Development-Process.md)
+### [Patch Submission Process](Patch-Submission-Process.md)
+### [Governance](Governance.md)
\ No newline at end of file
diff --git a/docs/help/Governance.md b/docs/help/Governance.md
new file mode 100644
index 0000000000..67d352297a
--- /dev/null
+++ b/docs/help/Governance.md
@@ -0,0 +1,81 @@
+* [Project Roles](#project-roles)
+ - [Contributor](#contributor)
+ - [Committer](#committer)
+ - [Maintainer](#maintainer)
+ - [Selection of Committers and Maintainers](#selection-of-committers-and-maintainers)
+ - [Revocation of Committers/Maintainers status](#revocation-of-committersmaintainers-status)
+ - [Steering Committee](#steering-committee)
+* [Decision Making Process](#decision-making-process)
+
+## Project Roles
+
+The IoT.js project recognizes the following formal roles: Contributor, Committer, and Maintainer.
+
+* [Assigned people](Assigned-people.md)
+
+#### Contributor
+A _Contributor_ is a developer who wishes to contribute to the project, at any level. Contributors who show dedication and skill are rewarded with additional rights and responsibilities. Their opinions weigh more when decisions are made, in a fully meritocratic fashion.
+
+Contributors are granted the following rights and responsibilities:
+* Right to contribute code, documentation, translations, artwork, etc.
+* Right to report defects (bugs) and suggestions for enhancement.
+* Right to participate in the process of reviewing contributions by others.
+* Right to initiate and participate in discussions in any communication methods.
+* Right to approach any member of the community with matters they believe to be important.
+* Responsibility to abide by decisions, once made. They are welcome to provide new, relevant information to reopen decisions.
+* Responsibility for issues and bugs introduced by one’s own contributions.
+* Responsibility to respect the rules of the community.
+* Responsibility to provide constructive advice whenever participating in discussions and in the review of contributions.
+
+#### Committer
+A _Committer_ is a Contributor who is also responsible for the maintenance of IoT.js source code.
+
+Committers have the following rights and responsibilities, in addition to those listed for Contributors:
+* Right to set goals for the short and medium terms for the project being maintained, alongside the Maintainer.
+* Right to exceptionally make more invasive changes to the source code, when required.
+* Right to approve own contribution, after discussing with other Contributors.
+* Right and responsibility to participate in the feature development process.
+* Responsibility to ensure all contributions of the project have been reviewed within reasonable time.
+* Responsibility to ensure the quality of the code to expected levels.
+* Responsibility to monitor discussions in the community.
+* Responsibility to participate in the quality verification and release process, when those happen.
+
+#### Maintainer
+A _Maintainer_ is a Contributor who is also responsible for knowing, directing and anticipating the needs of a given IoT.js source code.
+
+Maintainers have the following rights and responsibilities, in addition to those listed for Contributors and Committers:
+* right to set the overall organization of the source code of the project
+* right to participate in the decision-making of the project, in conjunction with the Committers.
+* Responsibility to ensure all contributions of the project have been reviewed within reasonable time.
+ - In the reviewing, only Maintainers can give binding scores(refer to [Approval Path for PR(Pull Request)](#approval-path-for-prpull-request))
+
+#### Selection of Committers and Maintainers
+
+A candidate for the Committer role should be one of the Contributors who has submitted at least 10 non-trivial patches in project and has shown characteristics consistent with the requirements of the Committer role.
+A candidate for the Maintainer role should be one of the Committers.
+To be a candidate for the Committer or Maintainer, a Contributor can self-nominate with proper evidences.
+
+The selection process should be achieved by consensus of the Contributors active in. If consensus cannot be achieved, Maintainers will make the decision by voting.
+
+#### Revocation of Committers/Maintainers Status
+
+A Maintainer or a Committer who intentionally abused his review privilege may have it temporarily suspended on the request of other Committers or Maintainers. Committers and Maintainers not including the person under consideration should discuss on the revocation of the person. If consensus cannot be reached, Maintainers will make the decision by voting.
+
+#### Steering Committee
+
+_Steering Committee_ oversees and guides the progress of IoT.js project.
+
+The Steering Committee have the following responsibilities:
+
+* responsibility to oversee the health of the project community.
+* responsibility to oversee and facilitate the development of the IoT.js source code under the governance rules of the IoT.js Open Source project.
+* responsibility to guide and direct the development towards goals.
+* responsibility to sets the goals and roadmap for the project
+
+## Decision Making Process
+
+Decisions in the IoT.js project are made always at the lowest level possible that is applicable for the decision in question. Decision makers always need to keep in mind the rules of community and the IoT.js goals and roadmap.
+
+* Individual Contributors are making decisions every time they submit changes in the form of deciding what to implement and how to go about it.
+* Two or more Contributors also make decisions when participating in discussions in community, on bug or feature reports, in reviewing of commits. Their arguments in why a given decision should be made are part of the consensus that needs to be reached for the decision. At this level, the principle of meritocracy is important, as the opinion of those who have contributed more will be given more weight in the consensus-building.
+* If those Contributors cannot agree and reach consensus on a decision, then IoT.js provides for decisions to be made by Maintainers following their own decision-making process, avoiding stalemates.
\ No newline at end of file
diff --git a/docs/IoT.js-Developer's-Certificate-of-Origin-1.0.md b/docs/help/IoT.js-Developer's-Certificate-of-Origin-1.0.md
similarity index 100%
rename from docs/IoT.js-Developer's-Certificate-of-Origin-1.0.md
rename to docs/help/IoT.js-Developer's-Certificate-of-Origin-1.0.md
diff --git a/docs/help/Patch-Submission-Process.md b/docs/help/Patch-Submission-Process.md
new file mode 100644
index 0000000000..a6ad0c4341
--- /dev/null
+++ b/docs/help/Patch-Submission-Process.md
@@ -0,0 +1,40 @@
+The following guidelines on the submission process are provided to help you be more effective when submitting code to the IoT.js project.
+
+When development is complete, a patch set should be submitted via Github pull requests. A review of the patch set will take place. When accepted, the patch set will be integrated into the master branch, verified, and tested. It is then the responsibility of the authoring developer to maintain the code throughout its lifecycle.
+
+Please submit all patches in public by opening a pull request. Patches sent privately to Maintainers and Committers will not be considered. Because the IoT.js Project is an Open Source project, be prepared for feedback and criticism-it happens to everyone-. If asked to rework your code, be persistent and resubmit after making changes.
+
+#### 1. Scope the patch
+
+Smaller patches are generally easier to understand and test, so please submit changes in the smallest increments possible, within reason. Smaller patches are less likely to have unintended consequences, and if they do, getting to root cause is much easier for you and the Maintainers and Committers. Additionally, smaller patches are much more likely to be accepted.
+
+#### 2. Sign your work with the [IoT.js DCO](IoT.js-Developer's-Certificate-of-Origin-1.0.md)
+
+The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an Open Source patch. The sign-off is required for a patch to be accepted.
+
+#### 3. Open [a Github pull request](https://github.com/Samsung/iotjs/pulls)
+
+#### 4. What if my patch is rejected?
+
+It happens all the time, for many reasons, and not necessarily because the code is bad. Take the feedback, adapt your code, and try again. Remember, the ultimate goal is to preserve the quality of the code and maintain the focus of the Project through intensive review.
+
+Maintainers and Committers typically have to process a lot of submissions, and the time for any individual response is generally limited. If the reason for rejection is unclear, please ask for more information to the Maintainers and Committers.
+If you have a solid technical reason to disagree with feedback and you feel that reason has been overlooked, take the time to thoroughly explain it in your response.
+
+#### 5. Code review
+
+Code review can be performed by all the members of the Project (not just Maintainers and Committers). Members can review code changes and share their opinion by comments with the following principles:
+* Discuss code; never discuss the code's author.
+* Respect and acknowledge contributions, suggestions, and comments.
+* Listen and be open to all different opinions.
+* Help each other.
+
+Changes are submitted via pull requests and only the Maintainers and Committers should approve or reject the pull request.
+Changes should be reviewed in reasonable amount of time. Maintainers and Committers should leave changes open for some time (at least 1 full business day) so others can offer feedback. Review times increase with the complexity of the review.
+
+### Tips on GitHub Pull Requests
+* Fork the GitHub repository(https://guides.github.com/activities/forking/) and clone it locally.
+Connect your local repository to the original upstream repository by adding it as a remote.
+Pull in upstream changes often to stay up-to-date so that when you submit your pull request, merge conflicts will be less likely.
+* For more details, see [GitHub fork synching guidelines](https://help.github.com/articles/syncing-a-fork/).
+[Create a branch](https://guides.github.com/introduction/flow/) for your edits.
\ No newline at end of file