Merge pull request #86 from fh1ch/chore/community-templates

Chore/community templates

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,23 @@
+Node Version: `X.Y.Z`
+
+Node BACstack Version: `X.Y.Z`
+
+- [ ] Bug Report
+- [ ] Feature Request
+- [ ] Question
+
+### Feature Request / Question
+
+-
+
+### Current Behaviour (Bug Report)
+
+-
+
+### Expected Behaviour  (Bug Report)
+
+-
+
+### Steps to reproduce Issue  (Bug Report)
+
+-

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,14 @@
+### Checklist
+
+- [ ] I've read and followed the [Contribution Guide](https://github.com/fh1ch/node-bacstack/blob/master/CONTRIBUTING.md).
+- [ ] My commit messages reference affected issues and mention breaking changes if applicable.
+- [ ] I've updated / wrote inline documentation for the source code affected by my changes.
+- [ ] All mandatory CI checks have passed (see when Pull Request has been submitted).
+
+### Open Question
+
+-
+
+### What does this Pull Request do
+
+-

CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# 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, 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 fabio@fh1.ch. The project team will
+review and investigate all complaints, and will respond in a way that it deems
+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 [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -0,0 +1,61 @@
+# Contributing
+
+Implementing and maintaining a protocol stack is a lot of work, therefore any
+help is appreciated, from creating issues, to contributing documentation, fixing
+issues and adding new features.
+
+Please follow the best-practice contribution guidelines as mentioned below when
+submitting any changes.
+
+### Conventional Changelog
+
+This module has a changelog which is automatically generated based on Git commit
+messages. This mechanism requires that all commit messages comply with the
+[Conventional Changelog](https://github.com/bcoe/conventional-changelog-standard/blob/master/convention.md).
+You can check if your commit messages complies with those guidelines by using:
+
+``` sh
+npm run changelog
+```
+
+### Code Style
+
+This module uses the [Google JavaScript Code-Style](https://google.github.io/styleguide/javascriptguide.xml)
+and enforces it using [JSCS](http://jscs.info/) as additional linter beneath
+[JSHint](http://jshint.com/). You can test if your changes comply with the code
+style by executing:
+
+``` sh
+npm run lint
+```
+
+### Testing and Coverage
+
+Testing is done using [Mocha](https://mochajs.org/) and is separated into two
+sets, `unit` and `integration`. While unit tries to test on function level,
+including synthetic decoding and encoding, the integration tests are using real
+recorded data and are only mocking the transport layer.
+
+For both sets, the test-coverage is calculated using [Istanbul](https://istanbul.js.org/).
+Running the tests and calculating the coverage can be done locally by executing:
+
+``` sh
+npm run test
+npm run integration
+```
+
+It is expected that new features or fixes do not negatively impact the test
+results or the coverage.
+
+### Documentation
+
+The API documentation is generated using [JSDoc](http://usejsdoc.org/) and
+relies on in-line JSDoc3 syntax. The documentation can also be built locally by
+executing:
+
+``` sh
+npm run docs
+```
+
+It is expected that new features or changes are reflected in the documentation
+as well.

README.md

@@ -94,61 +94,8 @@ Implementing and maintaining a protocol stack is a lot of work, therefore any
 help is appreciated, from creating issues, to contributing documentation, fixing
 issues and adding new features.
 
-Please follow the best-practice contribution guidelines as mentioned below when
-submitting any changes.
-
-### Conventional Changelog
-
-This module has a changelog which is automatically generated based on Git commit
-messages. This mechanism requires that all commit messages comply with the
-[Conventional Changelog](https://github.com/bcoe/conventional-changelog-standard/blob/master/convention.md).
-You can check if your commit messages complies with those guidelines by using:
-
-``` sh
-npm run changelog
-```
-
-### Code Style
-
-This module uses the [Google JavaScript Code-Style](https://google.github.io/styleguide/javascriptguide.xml)
-and enforces it using [JSCS](http://jscs.info/) as additional linter beneath
-[JSHint](http://jshint.com/). You can test if your changes comply with the code
-style by executing:
-
-``` sh
-npm run lint
-```
-
-### Testing and Coverage
-
-Testing is done using [Mocha](https://mochajs.org/) and is separated into two
-sets, `unit` and `integration`. While unit tries to test on function level,
-including synthetic decoding and encoding, the integration tests are using real
-recorded data and are only mocking the transport layer.
-
-For both sets, the test-coverage is calculated using [Istanbul](https://istanbul.js.org/).
-Running the tests and calculating the coverage can be done locally by executing:
-
-``` sh
-npm run test
-npm run integration
-```
-
-It is expected that new features or fixes do not negatively impact the test
-results or the coverage.
-
-### Documentation
-
-The API documentation is generated using [JSDoc](http://usejsdoc.org/) and
-relies on in-line JSDoc3 syntax. The documentation can also be built locally by
-executing:
-
-``` sh
-npm run docs
-```
-
-It is expected that new features or changes are reflected in the documentation
-as well.
+Please follow the [Contribution Guide](CONTRIBUTING.md) when submitting any
+changes.
 
 ## License