diff --git a/.github/issue_template.md b/.github/issue_template.md
new file mode 100644
index 000000000..bb5359a54
--- /dev/null
+++ b/.github/issue_template.md
@@ -0,0 +1,46 @@
+<!--- Remove text and sections that do not apply -->
+
+The issue tracker is only for reporting bugs or asking for feature requests and bugs.
+If you need technical assistance for running the IOTA Go Library please consult the #go channel on discord (https://discord.gg/jrxApWC) or https://forum.helloiota.com/Technology/Help.
+If you have general questions on IOTA you can go to https://iota.stackexchange.com/, or https://helloiota.com/, or browse discord channels (https://discord.gg/C88Wexg).
+
+
+<!----Format For Reporting Bugs------->
+### Bug description
+A general description of the bug.
+
+### Steps To Reproduce
+1. 
+2. 
+3. 
+
+### Expected behaviour
+What should happen.
+
+### Actual behavior
+What really happened.
+
+### Errors
+Paste any errors that you see.
+
+
+
+<!----Format For Feature Requests------->
+*Note*
+The feature request will probably be integrated faster if you do a pull request for it.
+If you want to discuss the feature before you actually write the code you are welcome to do it by first submitting an issue.
+
+### Description
+Briefly describe the feature you want.
+
+### Motivation
+Explain why this feature is needed.
+
+### Requirements
+Create a list of what you want this feature request to fulfill.
+
+### Open Questions (optional)
+Anything you want to discuss.
+
+### Am I planning to do it myself with a PR?
+Yes/No.
\ No newline at end of file
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
new file mode 100644
index 000000000..00dfcd771
--- /dev/null
+++ b/.github/pull_request_template.md
@@ -0,0 +1,40 @@
+<!---
+Hints for a successful PR:
+1. It is recommended that before you submit a PR to IOTA, to open an issue first and assign yourself.
+This way you may get inputs and discover parallel PRs to the one you want to submit.
+2. In case of a big PR, consider breaking it up to smaller PRs. This will help getting it merged in an incremental process.
+3. Note that a PR should have a *single* area of responsibility. If your PR does more than one thing than it should be split to several PRs!!!!!
+4. It will be helpful if you make additional comments on the code via github PR review to explain the choices you made
+-->
+
+# Description
+
+Please include a summary of the change. Include the motivation for the change.
+
+Fixes # (issue)
+
+## Type of change
+
+Please delete options that are not relevant.
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] Enhancement (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] Documentation Fix
+
+# How Has This Been Tested?
+
+Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
+
+- [ ] Test A
+- [ ] Test B
+
+
+# Checklist:
+
+- [ ] My code follows the style guidelines of this project
+- [ ] I have performed a self-review of my own code
+- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] I have made corresponding changes to the documentation
+- [ ] I have added tests that prove my fix is effective or that my feature works
+- [ ] New and existing unit tests pass locally with my changes
\ No newline at end of file