rcorp · riteshe63 · Nov 7, 2016 · Nov 7, 2016 · Nov 23, 2016 · Nov 30, 2016
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -44,15 +44,12 @@ Good bug reports are extremely helpful, so thanks!
 
 Guidelines for bug reports:
 
-
 1. **Use the GitHub issue search** &mdash; check if the issue has already been
    reported.
 
 2. **Check if the issue has been fixed** &mdash; try to reproduce it using the
    latest `master` or development branch in the repository.
 
-
-
 A good bug report shouldn't leave others needing to chase you up for more
 information. Please try to be as detailed as possible in your report. What is
 your environment? What steps will reproduce the issue? What browser(s) and OS
@@ -83,55 +80,8 @@ Please adhere to the [coding guidelines](#code-guidelines) used throughout the
 project (indentation, accurate comments, etc.) and any other requirements
 (such as test coverage).
 
-Adhering to the following process is the best way to get your work
-included in the project:
-
-1. [Fork](https://help.github.com/fork-a-repo/) the project, clone your fork,
-   and configure the remotes:
-
-   ```bash
-   # Clone your fork of the repo into the current directory
-   git clone https://github.com/<your-username>/standard-project-structure.git
-   # Navigate to the newly cloned directory
-   cd standard-project-structure
-   # Assign the original repo to a remote called "upstream"
-   git remote add upstream https://github.com/rcorp/standard-project-structure.gitg
-   ```
-
-2. If you cloned a while ago, get the latest changes from upstream:
-
-   ```bash
-   git checkout master
-   git pull upstream master
-   ```
-
-3. Create a new topic branch (off the main project development branch) to
-   contain your feature, change, or fix:
-
-   ```bash
-   git checkout -b <topic-branch-name>
-   ```
-
-4. Commit your changes in logical chunks. Please adhere to these [git commitg
-   message guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
-   or your code is unlikely be merged into the main project. Use Git's
-   [interactive rebase](https://help.github.com/articles/interactive-rebase)
-   feature to tidy up your commits before making them public.
-
-5. Locally merge (or rebase) the upstream development branch into your topic branch:
-
-   ```bash
-   git pull [--rebase] upstream master
-   ```
-
-6. Push your topic branch up to your fork:
-
-   ```bash
-   git push origin <topic-branch-name>
-   ```
-
-7. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/)
-    with a clear title and description against the `master` branch.
+Adhering to the process is the best way to get your work included in the project. 
+Firstly [Fork](https://help.github.com/articles/fork-a-repo/) a project and after that work and [create pull request](https://help.github.com/articles/creating-a-pull-request-from-a-fork/)
 
 ## Code guidelines
 

diff --git a/README.md b/README.md
@@ -28,7 +28,6 @@ This is a work in progress but we are getting closer to a Public Launch! We need
 8. [Documentation](#documentation)
 
 ## Linting
-
 All code should look like a single person typed it, no matter how many people contributed so its easy to read and contribute.
 
 Linting is the process of checking the source code for Programmatic as well as Stylistic errors. This is most helpful in identifying some common and uncommon mistakes that are made during coding.
@@ -46,59 +45,10 @@ Add linters and Atom to your project. For this, we will run this command:
 #### Usage
 
     grunt lint
+
+[Read more...](./docs/linter.md)
 
- - Runs all linters installed.
-
-<table>
-<tr>
-<td><b>Language</td>
-<td><b>Linters</td><td><b>Rules</td><td><b>Why?</td>
-</tr>
-<tr>
-<td>Javascript</td>
-<td> <a href="https://github.com/eslint/eslint/"> ESLint </a> </td>
-<td> <a href="https://github.com/airbnb/javascript"> Airbnb Style Guide </a> </td>
-<td> 
-  <a href="https://github.com/rcorp/standard-project-structure/issues/4"> #4 </a>,
-  <a href="https://github.com/rcorp/standard-project-structure/issues/6"> #6 </a> 
-</td>
-</tr>
-<tr>
-<td>Coffeescript</td>
-<td> <a href="https://github.com/clutchski/coffeelinta"> CoffeeLint </a> </td>
-<td> </td>
-<td> <a href="https://github.com/rcorp/standard-project-structure/issues/4"> #4 </a> </td>
-</tr>
-<tr>
-<td>CSS</td>
-<td> <a href="https://github.com/CSSLint/csslint"> StyleLint </a> </td>
-<td> <a href="https://github.com/stylelint/stylelint-config-standard"> StyleLint Standard Config </a> </td>
-<td> 
-  <a href="https://github.com/rcorp/standard-project-structure/issues/4"> #4 </a>,
-  <a href="github.com/rcorp/standard-project-structure/issues/11"> #11 </a> 
-</td>
-</tr>
-<tr>
-<td>HTML</td>
-<td> <a href="https://github.com/yaniswang/HTMLHint"> HTMLHint </a> </td>
-<td> <a href="https://github.com/yaniswang/HTMLHint"> HTML Standard Config </a> </td>
-<td> 
-  <a href="https://github.com/rcorp/standard-project-structure/issues/4"> #4 </a>, 
-  <a href="https://github.com/rcorp/standard-project-structure/issues/13"> #13 </a>
-</td>
-</tr>
-<tr>
-<td>Typescript</td>
-<td> <a href="https://github.com/palantir/tslint"> TSLint </a> </td>
-<td> <a href="https://github.com/Microsoft/tslint-microsoft-contrib"> Microsoft tslint Standard </a> </td>
-<td> 
-  <a href="https://github.com/rcorp/standard-project-structure/issues/4"> #4 </a>,
-  <a href="https://github.com/rcorp/standard-project-structure/issues/15"> #15 </a>
-</tr>
-</table>
-
-### Testing
-
+## Testing
 we do manual testing of some project, we generally run some command, and check the output, or exit code to verify if the command did what it was supposed to do.
 
 Some Framework or tools uses to your project like, Mocha, Code Coverage etc.
@@ -107,28 +57,28 @@ Some Framework or tools uses to your project like, Mocha, Code Coverage etc.
 
 Add Automate test cases our project, using this command:
 
-    yo ./standard-project-structure/generators/task-runner
+    yo ./standard-project-structure/generators/test
 
 #### Usage
 
     grunt test
     grunt cover    
 
+[Read more...](./docs/testing.md)
 
-#### Unit Testing
+### Unit Testing
 
-#### Functional Testing
+### Functional Testing
 
-### Continuous Integration
+## Continuous Integration
 
-### Dependency Management
+## Dependency Management
 
-#### NPM
+### NPM
 
-#### Bower
-
-### Task Runners
+### Bower
 
+## Task Runners
 Task Runner is a process of automation of task. You will have to do less work when performing repetitive tasks like bundling, unit testing, linting, etc.
 
 #### Installation
@@ -137,24 +87,24 @@ Add Task Runner our project, using this command:
 
     yo ./standard-project-structure/generators/task-runner 
 
-### Project Structure
+[Read more...](./docs/task-runner.md)
 
+## Project Structure
 Making documentation accessible enables people to learn about a project; making it easy to update ensures that documentation stays relevant.
 
 #### Installation
 
 Run these command using create Initial Project Structure.
 
     yo ./standard-project-structure/generators/projectStructure
-
-### Release Management
-
-We attempt to stick to [Semantic Versioning](http://semver.org/). Most of the time, development should be against a new minor version - fixing bugs and adding new features that are backwards compatible.
-[Read more...](https://github.com/rcorp/standard-project-structure/blob/masterRELEASE.md)
-
-### Documentation
-
 
+[Read more...](./docs/project-structure.md)
 
+## Release Management
+We attempt to stick to [Semantic Versioning](http://semver.org/). Most of the time, development should be against a new minor version - fixing bugs and adding new features that are backwards compatible.
+[Read more...](./docs/release.md)
 
+## Documentation
 
+## License
+standard-project-structure (SPS) is licensed under the Apache 2.0 license, see [LICENSE](./LICENSE) for details.
diff --git a/docs/linter.md b/docs/linter.md
@@ -3,15 +3,10 @@
 All code should look like a single person typed it, no matter how many people contributed so its easy to read and contribute.
 
 Linting is the process of checking the source code for Programmatic as well as Stylistic errors. This is most helpful in identifying some common and uncommon mistakes that are made during coding.
-We use `Atom` code editor for linting. So we need to install Atom for this.
 
 #### Installation
 
-Check whether your system has Yeoman installed or not. If Yeoman is not installed, then we need to run these command:
-
-    npm install -g yo
-
-After that Add linters and Atom to your project. For this, we will run this command:
+Add linters and Atom to our project. For this, we will run this command:
 
     yo ./standard-project-structure/generators/linter
 

diff --git a/docs/project-structure.md b/docs/project-structure.md
@@ -4,13 +4,14 @@ Making documentation accessible enables people to learn about a project; making
 
 > Initial Project Structure created to in the project.
 
-### Create Generic Project Structure
-Yeoman is required. So firstly we need to check whether yeoman is installed or not.
+## Create Generic Project Structure
 
-    npm install -g yo
-After that run these command using create Initial Project Structure.
+#### Installation
+
+Add Initial Project Structue to our project. For this, we will run this command:
 
     yo ./standard-project-structure/generators/projectStructure
+
 The above command will create some folder and files like:
 
     .

diff --git a/docs/release.md b/docs/release.md
@@ -2,24 +2,29 @@
 
 Follow the instructions in [`CONTRIBUTING.md`](https://github.com/rcorp/standard-project-structure/blob/master/CONTRIBUTING.md) during development.
 
-### Version
+## Version
 
 We attempt to stick to [Semantic Versioning](http://semver.org/). Most of the time, development should be against a new minor version - fixing bugs and adding new features that are backwards compatible.
 
 The current version lives in the file `/package.json`. This version will be the version number that is currently released. When releasing a new version, update `package.json` file.
 
-###How does it work?
+## Testing
+
+- [ ] Run "grunt lint"
+- [ ] Run "grunt test" & "grunt cover"
+
+##How does it work?
 
 Firstly check that your project is completed or not, for example we take into account whether all test cases is completed, linter errors are done, documentation etc. After that [release](https://help.github.com/articles/creating-releases/) or [tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) your project and push it to github repo.
 
 You can do the above process manually as well. You have to remember what major, minor and patch means. You have to remember to push both commits and tags. You have to wait for the CI to pass. After that,
 ```
-npm version <version>
-git push origin master --tags
+git tag vX.Y.Z
+git push origin --tags
 ```
-### Release the NPM
+## Release the NPM
 
-1. `npm adduser` to save your credentials locally
-1. `npm publish .` to publish what's in `package.json`
+- [ ] Log into npm (`npm login`)
+- [ ] Publish to NPM (`npm publish —-tag <TagForInstall>`, e.g. `npm publish --tag beta` or `npm publish` to release latest production framework)
 
 
diff --git a/docs/task-runner.md b/docs/task-runner.md
@@ -9,18 +9,20 @@ Firstly you need a `package.json`,  if this file exists in our project then we w
 
     npm init
 
-###Tasks
+##Tasks
+
 Tasks are the modules that performs a specified job. They are defined in the Gruntfile.
 
 Developers can load predefined tasks from existing Grunt plugins and/or write custom code to define their own tasks depending on their requirements. Once defined, these tasks can be run from the command line by simply executing grunt `taskname`. If the `taskname` defined in the Gruntfile is 'default' then simply executing grunt will suffice.
 
-###Add Task Runner in the Project
-Add some modules like:
+##Add Task Runner in the Project
+
+#### Installation
 
-    npm install -g yo
-After that add Task Runner in the project using this command:
+Add Task Runner to our project. For this, we will run this command:
 
     yo ./standard-project-structure/generators/task-runner
+
 Files and folders will be created.
 
 `Gruntfile.js` - Add only load-grunt-config plugin (load-grunt-config is a Grunt library that allows you to break up your Gruntfile config by task).

diff --git a/docs/testing.md b/docs/testing.md
@@ -0,0 +1,30 @@
+#Testing 
+
+we do manual testing of some project, we generally run some command, and check the output, or exit code to verify if the command did what it was supposed to do.
+
+Some Framework or tools uses to your project like, Mocha, Code Coverage etc.
+
+##Mocha
+
+Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases.
+[Read More...](https://mochajs.org/)
+
+##Code Coverage
+
+code coverage is a way of ensuring that your tests are actually testing your code. When you run your tests you are presumably checking that you are getting the expected results. Code coverage will tell you how much of your code you exercised by running the test. Your tests may all pass with flying colours, but if you've only tested 50% of your code, how much confidence can you have in it?
+
+#### Installation
+
+Add Mocha and Code Coverage using test cases to our project. For this, we will run this command:
+
+    yo ./standard-project-structure/generators/test
+
+#### Usage
+
+Test cases Run using Mocha
+
+    grunt test
+
+Test cases check using Code Coverage
+
+    grunt cover