docs: add contributing and github templates (close #23, #1061)

CODE_OF_CONDUCT.md

@@ -0,0 +1,73 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+education, socio-economic status, nationality, personal appearance, race,
+religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at dl_javascript@nhnent.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org

CONTRIBUTING.md

@@ -0,0 +1,93 @@
+# Contributing to TOAST UI
+
+First off, thanks for taking the time to contribute! 🎉 😘 ✨
+
+The following is a set of guidelines for contributing to TOAST UI. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
+
+## Reporting Bugs
+Bugs are tracked as GitHub issues. Search the list and try reproduce on [demo][demo] before you create an issue. When you create an issue, please provide the following information by filling in the template.
+
+Explain the problem and include additional details to help maintainers reproduce the problem:
+
+* **Use a clear and descriptive title** for the issue to identify the problem.
+* **Describe the exact steps which reproduce the problem** in as many details as possible. Don't just say what you did, but explain how you did it. For example, if you moved the cursor to the end of a line, explain if you used a mouse or a keyboard.
+* **Provide specific examples to demonstrate the steps.** Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets on the issue, use Markdown code blocks.
+* **Describe the behavior you observed after following the steps** and point out what exactly is the problem with that behavior.
+* **Explain which behavior you expected to see instead and why.**
+* **Include screenshots and animated GIFs** which show you following the described steps and clearly demonstrate the problem.
+
+## Suggesting Enhancements
+In case you want to suggest for TOAST UI Editor, please follow this guideline to help maintainers and the community understand your suggestion.
+Before creating suggestions, please check [issue list](https://github.com/nhnent/tui.editor/labels/feature%20request) if there's already a request.
+
+Create an issue and provide the following information:
+
+* **Use a clear and descriptive title** for the issue to identify the suggestion.
+* **Provide a step-by-step description of the suggested enhancement** in as many details as possible.
+* **Provide specific examples to demonstrate the steps.** Include copy/pasteable snippets which you use in those examples, as Markdown code blocks.
+* **Include screenshots and animated GIFs** which helps demonstrate the steps or point out the part of TOAST UI Editor which the suggestion is related to.
+* **Explain why this enhancement would be useful** to most TOAST UI users.
+* **List some other text editors or applications where this enhancement exists.**
+
+## First Code Contribution
+
+Unsure where to begin contributing to TOAST UI? You can start by looking through these `document`, `good first issue` and `help wanted` issues:
+
+* **document issues**: issues which should be reviewed or improved.
+* **good first issues**: issues which should only require a few lines of code, and a test or two.
+* **help wanted issues**: issues which should be a bit more involved than beginner issues.
+
+## Pull Requests
+
+### Development WorkFlow
+- Set up your development environment
+- Make change from a right branch
+- Be sure the code passes `npm run lint`, `npm run test`
+- Make a pull request
+
+### Development environment
+- Prepare your machine node and it's packages installed.
+- Checkout our repository
+- Install dependencies by `npm install && bower install`
+- Start webpack-dev-server by `npm run serve`
+
+### Make changes
+#### Checkout a branch
+- **develop**: PR base branch. merge features, updates for next minor or major release
+- **master**: bug fix or document update for next patch release. develop branch will rebase every time master branch update. so keep code change to a minimum.
+- **production**: lastest release branch with distribution files. never make a PR on this
+- **gh-pages**: API docs, examples and demo
+
+#### Check Code Style
+Run `npm run eslint` and make sure all the tests pass.
+
+#### Test
+Run `npm run test` and verify all the tests pass.
+If you are adding new commands or features, they must include tests.
+If you are changing functionality, update the tests if you need to.
+
+#### Commit
+Follow our [commit message conventions](./docs/COMMIT_MESSAGE_CONVENTION.md).
+
+### Yes! Pull request
+Make your pull request, then describe your changes.
+#### Title
+Follow other PR title format on below.
+```
+    <Type>: Short Description (fix #111)
+    <Type>: Short Description (fix #123, #111, #122)
+    <Type>: Short Description (ref #111)
+```
+* capitalize first letter of Type
+* use present tense: 'change' not 'changed' or 'changes'
+
+#### Description
+If it has related to issues, add links to the issues(like `#123`) in the description.
+Fill in the [Pull Request Template](./docs/PULL_REQUEST_TEMPLATE.md) by check your case.
+
+## Code of Conduct
+This project and everyone participating in it is governed by the [Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to dl_javascript@github.com.
+
+> This Guide is base on [atom contributing guide](https://github.com/atom/atom/blob/master/CONTRIBUTING.md), [CocoaPods](http://guides.cocoapods.org/contributing/contribute-to-cocoapods.html) and [ESLint](http://eslint.org/docs/developer-guide/contributing/pull-requests)
+
+[demo]:https://nhnent.github.io/tui.editor/

README.md

@@ -34,10 +34,10 @@
 ### CommonMark + GFM Specifications
 
 Today *CommonMark* is the de-facto *Markdown* standard. *GFM (GitHub Flavored Markdown)* is another popular specification based on *CommonMark* - maintained by *GitHub*, which is known as the biggest *Markdown* user.
-**ToastUI Editor** respects both [*CommonMark*](http://commonmark.org/) and [*GFM*](https://github.github.com/gfm/) specifications. Write documents with ease using productive tools provided by **ToastUI Editor**. You can open this document wherever the specifications are supported.
+**TOAST UI Editor** respects both [*CommonMark*](http://commonmark.org/) and [*GFM*](https://github.github.com/gfm/) specifications. Write documents with ease using productive tools provided by **TOAST UI Editor**. You can open this document wherever the specifications are supported.
 
 ### Powerful Extensions
-*CommonMark* and *GFM* are great, but we often face requirements beyond the specifications. The **ToastUI Editor** comes with powerful **Extensions** in compliance with the *Markdown* syntax, while also providing APIs so you can develop your own extensions.
+*CommonMark* and *GFM* are great, but we often face requirements beyond the specifications. The **TOAST UI Editor** comes with powerful **Extensions** in compliance with the *Markdown* syntax, while also providing APIs so you can develop your own extensions.
 
 Here are some of the extensions you can start with:
 
@@ -49,9 +49,9 @@ Here are some of the extensions you can start with:
  To learn more about **Extensions** check the [Extension Docs](https://github.com/nhnent/tui.editor/wiki/Extensions)
 
 ## 🎨 Features
-**ToastUI Editor** provides **Markdown mode** and **Wysiwyg mode**.
+**TOAST UI Editor** provides **Markdown mode** and **Wysiwyg mode**.
 
-Some may like the productivity of *Markdown*, while others may be looking for a way to make it easier to edit. The **ToastUI Editor** can be the coordinator of both. It offers **Markdown mode** and **Wysiwyg mode**, which can be switched at any time during writing content. Both work together conveniently in one document.
+Some may like the productivity of *Markdown*, while others may be looking for a way to make it easier to edit. The **TOAST UI Editor** can be the coordinator of both. It offers **Markdown mode** and **Wysiwyg mode**, which can be switched at any time during writing content. Both work together conveniently in one document.
 
 ### Productive Markdown mode
 ![markdown image](https://user-images.githubusercontent.com/1215767/34354737-b98a0736-ea73-11e7-8375-d4c83b8894d8.png)
@@ -93,7 +93,7 @@ Below codes are for *npm*. If you are using *bower* please see [Getting started
 ### Editor
 
 #### HTML
-Place a `<div></div>` where you want ToastUI Editor rendered.
+Place a `<div></div>` where you want TOAST UI Editor rendered.
 ```html
 <body>
 ...
@@ -133,7 +133,7 @@ $('#editSection').tuiEditor({
 Find out more options [here](https://nhnent.github.io/tui.editor/api/latest/ToastUIEditor.html#ToastUIEditor)
 
 ### Viewer
-**ToastUI Editor** provides a **Viewer** in case you want to show *Markdown* content without loading the editor. The **Viewer** has much **lighter** than the editor.
+**TOAST UI Editor** provides a **Viewer** in case you want to show *Markdown* content without loading the editor. The **Viewer** has much **lighter** than the editor.
 
 ```javascript
 var Viewer = require('tui-editor/dist/tui-editor-Viewer');
@@ -160,7 +160,7 @@ var editor = Editor.factory({
 ...
 ```
 
-**ToastUI Editor** respects *CommonMark* and *GFM*. So any *Markdown* renderer including [markdownit](https://github.com/markdown-it/markdown-it) can handle the content it made. You can use any of those renderer without **Viewer** if you want.
+**TOAST UI Editor** respects *CommonMark* and *GFM*. So any *Markdown* renderer including [markdownit](https://github.com/markdown-it/markdown-it) can handle the content it made. You can use any of those renderer without **Viewer** if you want.
 
 
 ## 📙 Docs

docs/COMMIT_MESSAGE_CONVENTION.md

@@ -0,0 +1,49 @@
+# Commit Message Convention
+
+## Commit Message Format
+
+```
+<Type>: Short description (fix #1234)
+
+Logger description here if necessary
+
+BREAKING CHANGE: only contain breaking change
+```
+* Any line of the commit message cannot be longer 100 characters!
+
+## Revert
+```
+revert: commit <short-hash>
+
+This reverts commit <full-hash>
+More description if needed
+```
+
+## Type
+Must be one of the following:
+
+* **feat**: A new feature
+* **fix**: A bug fix
+* **docs**: Documentation only changes
+* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+* **refactor**: A code change that neither fixes a bug nor adds a feature
+* **perf**: A code change that improves performance
+* **test**: Adding missing or correcting existing tests
+* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation
+
+## Subject
+* use the imperative, __present__ tense: "change" not "changed" nor "changes"
+* don't capitalize the first letter
+* no dot (.) at the end
+* reference GitHub issues at the end. If the commit doesn’t completely fix the issue, then use `(refs #1234)` instead of `(fixes #1234)`.
+
+## Body
+
+* use the imperative, __present__ tense: "change" not "changed" nor "changes".
+* the motivation for the change and contrast this with previous behavior.
+
+## BREAKING CHANGE
+* This commit contains breaking change(s).
+* start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.
+
+This convention is based on [AngularJS](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits) and [ESLint](https://eslint.org/docs/developer-guide/contributing/pull-requests#step2)

ISSUE_TEMPLATE.md → docs/ISSUE_TEMPLATE.md

@@ -3,20 +3,17 @@ Thank you for your contribution.
 
 When it comes to write an issue, please, use the template below.
 To use the template is mandatory for submit new issue and we won't reply the issue that without the template.
-
-And you can write template's contents in Korean also.
 -->
 
-<!-- TEMPLATE -->
-
+<!-- BUG ISSUE TEMPLATE -->
 ## Version
 <!-- Write the version of the tui-editor you are currently using. -->
 
-## Development Environment
+## Test Environment
 <!-- Write the browser type, OS and so on -->
 
 ## Current Behavior
-<!-- Write a description of the current operation. You can add sample code, 'CodePen' or 'jsfiddle' links. -->
+<!-- Write a description of the detailed step to reproduce the current behavior. You can add sample code, 'CodePen' or 'jsfiddle' links. -->
 
 ```js
 // Write example code

docs/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,42 @@
+<!-- EDIT TITLE PLEASE -->
+<!-- It should be one of them
+  <ISSUE TYPE>: Short Description (<CLOSING TYPE> #<ISSUE NUMBERS>)
+  ex)
+  feat: add new feature (close #111)
+  fix: wrong behavior (fix #111)
+  chore: change build tool (ref #111)
+-->
+
+<!-- SPECIFY A ISSUE TYPE AT HEAD
+  feat: A new feature
+  fix: A bug fix
+  docs: Documentation only changes
+  style: Changes that do not affect the meaning of the code (white-space, formatting etc)
+  refactor: A code change that neither fixes a bug or adds a feature
+  perf: A code change that improves performance
+  test: Adding missing tests
+  chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
+-->
+
+<!-- ADD CLOSING TYPE AND ISSUE NUMBER AT TAIL
+  (<CLOSING TYPE> #<ISSUE NUMBERS>)
+  close: resolve not a bug(feature, docs, etc) completely
+  fix: resolve a bug completely
+  ref: not fully resolved or related to
+-->
+
+### Please check if the PR fulfills these requirements
+- [ ] It's submitted to right branch according to our branching model
+- [ ] It's right issue type on title
+- [ ] When resolving a specific issue, it's referenced in the PR's title (e.g. `fix #xxx[,#xxx]`, where "xxx" is the issue number)
+- [ ] The commit message follows our guidelines
+- [ ] Tests for the changes have been added (for bug fixes/features)
+- [ ] Docs have been added/updated (for bug fixes/features)
+- [ ] It does not introduce a breaking change or has description for the breaking change
+
+### Description
+
+
+
+---
+Thank you for your contribution to TOAST UI product. 🎉 😘 ✨

jsdoc.conf.js

@@ -47,7 +47,7 @@ module.exports = {
   },
   'opts': {
     'recurse': true,
-    'name': 'ToastUI Editor',
+    'name': 'TOAST UI Editor',
     'destination': `api/${version}`,
     'template': 'node_modules/tui-jsdoc-template',
     'tutorials': 'examples'