chore: add GitHub issue and PR templates

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,39 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ""
+labels: "bug"
+assignees: ""
+---
+
+**Describe the bug**
+
+<!-- A clear and concise description of what the bug is. -->
+
+**To Reproduce**
+
+<!-- Steps or code to reproduce the behavior. -->
+
+**Expected behavior**
+
+<!-- A clear and concise description of what you expected to happen. -->
+
+**Build environment**
+
+- bdk_tx tag/commit: <!-- e.g. v0.1.0, 3a07614 -->
+- OS+version: <!-- e.g. ubuntu 20.04.01, macOS 12.0.1, windows -->
+- Rust/Cargo version: <!-- e.g. 1.85.0 -->
+- Rust/Cargo target: <!-- e.g. x86_64-apple-darwin, x86_64-unknown-linux-gnu, etc. -->
+
+**Is this blocking production use?**
+
+- [ ] Yes
+- [ ] No
+
+**Project or organization (optional)**
+
+<!-- e.g. BitKey, LDK, personal wallet project, etc. -->
+
+**Additional context**
+
+<!-- Add any other context, logs, or error messages here. -->

.github/ISSUE_TEMPLATE/enhancement_request.md

@@ -0,0 +1,29 @@
+---
+name: Enhancement request
+about: Request a new feature or change to an existing feature
+title: ''
+labels: 'enhancement'
+assignees: ''
+---
+
+**Describe the enhancement**
+<!-- A clear and concise description of what you would like added or changed. -->
+
+**Use case**
+<!-- Tell us how you or others will use this new feature or change to an existing feature. -->
+
+**Impact**
+- [ ] Blocking production usage
+- [ ] Nice-to-have / UX improvement
+- [ ] Developer experience / maintainability
+
+**Are you using BDK in a production project?**
+- [ ] Yes
+- [ ] No
+- [ ] Not yet, but planning to
+
+**Project or organization (optional)**
+<!-- e.g. BitKey, LDK, personal wallet project, etc. -->
+
+**Additional context**
+<!-- Add any other context, links, or design thoughts here. -->

.github/pull_request_template.md

@@ -0,0 +1,20 @@
+<!-- You can erase any parts of this template not applicable to your Pull Request. -->
+
+### Description
+
+<!-- Describe the purpose of this PR, what's being adding and/or fixed -->
+
+### Notes to the reviewers
+
+<!-- In this section you can include notes directed to the reviewers, like explaining why some parts
+of the PR were done in a specific way -->
+
+### Changelog notice
+
+<!-- Notice the release manager should include in the release tag message changelog -->
+<!-- See https://keepachangelog.com/en/1.0.0/ for examples -->
+
+### Before submitting
+
+- [ ] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-tx/blob/master/CONTRIBUTING.md)
+- [ ] This PR breaks the existing API

CONTRIBUTING.md

@@ -0,0 +1,147 @@
+Contributing to bdk-tx
+==============================
+
+The BDK project operates an open contributor model where anyone is welcome to
+contribute towards development in the form of peer review, documentation,
+testing and patches.
+
+Anyone is invited to contribute without regard to technical experience,
+"expertise", OSS experience, age, or other concern. However, the development of
+cryptocurrencies demands a high-level of rigor, adversarial thinking, thorough
+testing and risk-minimization.
+Any bug may cost users real money. That being said, we deeply welcome people
+contributing for the first time to an open source project or picking up Rust while
+contributing. Don't be shy, you'll learn.
+
+Communications Channels
+-----------------------
+
+Communication about BDK happens primarily on the [BDK Discord](https://discord.gg/dstn4dQ).
+
+Discussion about code base improvements happens in GitHub [issues](https://github.com/bitcoindevkit/bdk-tx/issues) and
+on [pull requests](https://github.com/bitcoindevkit/bdk-tx/pulls).
+
+Contribution Workflow
+---------------------
+
+The codebase is maintained using the "contributor workflow" where everyone
+without exception contributes patch proposals using "pull requests". This
+facilitates social contribution, easy testing and peer review.
+
+To contribute a patch, the workflow is as follows:
+
+  1. Fork Repository
+  2. Create topic branch
+  3. Commit patches
+
+In general commits should be atomic and diffs should be easy to read.
+For this reason do not mix any formatting fixes or code moves with actual code
+changes. Further, each commit, individually, should compile and pass tests, in
+order to ensure git bisect and other automated tools function properly.
+
+When adding a new feature, thought must be given to the long term technical
+debt.
+Every new feature should be covered by functional tests where possible.
+
+When refactoring, structure your PR to make it easy to review and don't
+hesitate to split it into multiple small, focused PRs.
+
+The Minimum Supported Rust Version is **1.85.0** (enforced by our CI).
+
+Commits should cover both the issue fixed and the solution's rationale.
+These [guidelines](https://chris.beams.io/posts/git-commit/) should be kept in mind. Commit messages follow the ["Conventional Commits 1.0.0"](https://www.conventionalcommits.org/en/v1.0.0/) to make commit histories easier to read by humans and automated tools. All commits must be [GPG signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits).
+
+To facilitate communication with other contributors, the project is making use
+of GitHub's "assignee" field. First check that no one is assigned and then
+comment suggesting that you're working on it. If someone is already assigned,
+don't hesitate to ask if the assigned party or previous commenter are still
+working on it if it has been a while.
+
+Pull Request Checklist
+----------------------
+
+By opening a pull request, you are confirming that:
+
+- All commits are [GPG signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits).
+- The PR description links to the issue it solves, if one exists.
+- For new features, tests covering the new functionality have been added.
+- For new features, documentation for the new functionality has been added.
+- For bug fixes, tests reproducing the bug (and now passing) have been added.
+- Any breaking change to the existing API is clearly called out in the PR description.
+
+Deprecation policy
+------------------
+
+Where possible, breaking existing APIs should be avoided. Instead, add new APIs and
+use [`#[deprecated]`](https://github.com/rust-lang/rfcs/blob/master/text/1270-deprecation.md)
+to discourage use of the old one.
+
+Deprecated APIs are typically maintained for one release cycle. In other words, an
+API that has been deprecated with the 0.10 release can be expected to be removed in the
+0.11 release. This allows for smoother upgrades without incurring too much technical
+debt inside this library.
+
+If you deprecated an API as part of a contribution, we encourage you to "own" that API
+and send a follow-up to remove it as part of the next release cycle.
+
+Peer review
+-----------
+
+Anyone may participate in peer review which is expressed by comments in the
+pull request. Typically reviewers will review the code for obvious errors, as
+well as test out the patch set and opine on the technical merits of the patch.
+PR should be reviewed first on the conceptual level before focusing on code
+style or grammar fixes.
+
+To merge a PR we require all CI tests to pass, the PR has at least one approving review by a maintainer with write access, and reasonable criticisms have been addressed.
+
+Coding Conventions
+------------------
+
+This codebase uses spaces, not tabs.
+All public items must be documented. We adhere to the [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/about.html) with respect to documentation.
+
+The library is written using safe rust. Special consideration must be given to code which proposes an exception to the rule.
+
+All new features require testing. Tests should be unique and self-describing. If a test is in development or is broken or no longer useful, then a reason should be given for adding the `#[ignore]` attribute.
+
+Security
+--------
+
+Given the critical nature of BDK as a wallet library, we take security very seriously.
+
+For information on how to report security vulnerabilities, please refer to the [Security Policy](https://github.com/bitcoindevkit/bdk/blob/master/SECURITY.md).
+
+Testing
+-------
+
+Related to the security aspect, BDK developers take testing very seriously.
+Due to the modular nature of the project, writing new functional tests is easy
+and good test coverage of the codebase is an important goal.
+Refactoring the project to enable fine-grained unit testing is also an ongoing
+effort.
+
+First Time Contributors
+-----------------------
+
+If it is your first time contributing to the BDK family of libraries, welcome! We're glad to have you with us. If your
+first (or few first) PRs are focused on very small fixes to documentation, however, they might not meet our threshold
+for acceptance for first time contributors.
+
+Minor grammar and punctuation fixes aren't a good way to start contributing to a project, and instead we suggest you
+start with something a little more substantial. It's better to find an issue where you can demonstrate some knowledge
+of bitcoin or the code base, such as improving the substance of documentation, testing, or fixing some small issue
+even if it's considered low priority.
+
+This being said we are always looking forward to working with new folks interested in contributing to our libraries.
+If you are looking for issues to work on, check out the good first issue label and join our Discord server!
+
+Going further
+-------------
+
+You may be interested by Jon Atacks guide on [How to review Bitcoin Core PRs](https://github.com/jonatack/bitcoin-development/blob/master/how-to-review-bitcoin-core-prs.md)
+and [How to make Bitcoin Core PRs](https://github.com/jonatack/bitcoin-development/blob/master/how-to-make-bitcoin-core-prs.md).
+While there are differences between the projects in terms of context and
+maturity, many of the suggestions offered apply to this project.
+
+Overall, have fun :)