Repo chores (#2)

## What?

Adds community health files (PR and issue templates, contributing
guidelines).

## Why?

These files simplify contributions to the project.

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,23 @@
+---
+name: Bug report
+about: Use this template for reporting issues
+title: ''
+labels: bug
+assignees: ''
+---
+
+## Bug report
+
+<!-- Provide a concise description of the bug. -->
+
+### Steps to reproduce
+
+<!-- Describe steps to reproduce the bug. -->
+
+### Expected behavior
+
+<!-- Describe what you expected to happen from the library. -->
+
+### Environment
+
+<!-- Include relevant environment information. -->

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,19 @@
+---
+name: Feature request
+about: Use this template to request features
+title: ''
+labels: feat
+assignees: ''
+---
+
+## Feature request
+
+<!-- Provide a concise description of the feature you'd like to see implemented. -->
+
+### Why?
+
+<!-- Explain why this feature is important, guiding use case(s) etc. -->
+
+### Alternatives
+
+<!-- Briefly describe potential alternatives you've considered. -->

.github/pull_request_template.md

@@ -0,0 +1,12 @@
+## What?
+
+<!-- Briefly describe changes in the PR. If there are several things, organize them as a list. -->
+<!-- Example: This PR adds a PR template to the repo. -->
+<!-- If applicable, attach related issue(s) -->
+
+## Why?
+
+<!-- What is the motivation behind the PR? -->
+<!-- If applicable (e.g., for PRs implementing a large new feature), describe potential alternatives
+and their pros / cons. -->
+<!-- Example: PR templates simplify contributions to the project and structure it commit log. -->

CONTRIBUTING.md

@@ -0,0 +1,44 @@
+# Contributing to `compile-fmt`
+
+This project welcomes contribution from everyone, which can take form of suggestions / feature requests, bug reports, or pull requests.
+This document provides guidance how best to contribute.
+
+## Bug reports and feature requests
+
+For bugs or when asking for help, please use the bug issue template and include enough details so that your observations
+can be reproduced.
+
+For feature requests, please use the feature request issue template and describe the intended use case(s) and motivation
+to go for them. If possible, include your ideas how to implement the feature, potential alternatives and disadvantages.
+
+## Pull requests
+
+Please use the pull request template when submitting a PR. List the major goal(s) achieved by the PR
+and describe the motivation behind it. If applicable, like to the related issue(s).
+
+Optimally, you should check locally that the CI checks pass before submitting the PR. Checks included in the CI
+include:
+
+- Formatting using `cargo fmt --all`
+- Linting using `cargo clippy`
+- Linting the dependency graph using [`cargo deny`](https://crates.io/crates/cargo-deny)
+- Running the test suite using `cargo test`
+
+A complete list of checks can be viewed in [the CI workflow file](.github/workflows/ci.yml). The checks are run
+on the latest stable Rust version.
+
+### MSRV checks
+
+A part of the CI assertions is the minimum supported Rust version (MSRV). If this check fails, consult the error messages. Depending on
+the error (e.g., whether it is caused by a newer language feature used in the PR code, or in a dependency),
+you might want to rework the PR, get rid of the offending dependency, or bump the MSRV; don't hesitate to consult the maintainers.
+
+### No-std support checks
+
+Another part of the CI assertions is no-std compatibility of the project. To check it locally, install a no-std Rust target
+(CI uses `thumbv7m-none-eabi`) and build the project libraries for it. Keep in mind that no-std compatibility may be broken
+by dependencies.
+
+## Code of Conduct
+
+Be polite and respectful.

README.md

@@ -10,8 +10,14 @@
 
 This crate allows formatting values in compile time (e.g., in `const fn`s). The formatted values
 are not required to be constants; e.g., arguments or local vars in `const fn` can be formatted.
-The formatting logic is space-efficient; i.e., it allocates the least amount of bytes
-that can provably to be sufficient for all possible provided inputs.
+
+Features:
+
+- Zero dependencies.
+- Unconditionally `#[no_std]`-compatible.
+- The formatting logic is space-efficient; i.e., it allocates the least amount of bytes
+  that can provably to be sufficient for all possible provided inputs.
+- Does not rely on proc macros. This makes the library more lightweight.
 
 ## Why?
 
@@ -76,6 +82,11 @@ See crate docs for more examples of usage.
 - [`const_format`] provides general-purpose formatting of constant values. It doesn't seem to support
   "dynamic" / non-constant args.
 
+## Contributing
+
+All contributions are welcome! See [the contributing guide](CONTRIBUTING.md) to help
+you get involved.
+
 ## License
 
 `compile-fmt` is licensed under either of [Apache License, Version 2.0](LICENSE-APACHE)

src/lib.rs

@@ -4,9 +4,15 @@
 //!
 //! This crate allows formatting values in compile time (e.g., in `const fn`s). The formatted values
 //! are not required to be constants; e.g., arguments or local vars in `const fn` can be formatted.
-//! The formatting logic is space-efficient; i.e., it allocates the least amount of bytes
-//! that can provably to be sufficient for all possible provided inputs. As a consequence, non-constant
-//! formatted args require a [format specifier](Fmt).
+//!
+//! Features:
+//!
+//! - Zero dependencies.
+//! - Unconditionally `#[no_std]`-compatible.
+//! - The formatting logic is space-efficient; i.e., it allocates the least amount of bytes
+//!   that can provably to be sufficient for all possible provided inputs. As a consequence, non-constant
+//!   formatted args require a [format specifier](Fmt).
+//! - Does not rely on proc macros. This makes the library more lightweight.
 //!
 //! # Why?
 //!