docs: tighten and clarify CONTRIBUTING.md

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 0bb813c..0c98a4b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,338 +1,210 @@
-# Contributing to `Krux` firmware
+# Contributing to Krux firmware
 
-The development of `Krux` firmware is FOSS and community-effort-based and
-welcomes contributions from anyone. We are excited you are interested in
-helping us bring sovereign and private self-custody to everyone.
-
-We welcome contributions in many forms, including bug reports, feature
-requests, code contributions, and documentation improvements, from any
-contributors with any level of experience or expertise.
-
-Besides that, we ask that you respect others and follow the process
-outlined in this document.
-
----
-
-## Read the docs carefully
-
-We have a deep and a concise
-[documentation for users](https://selfcustody.github.io/krux). Besides
-that, not all of them read the documentation properly.
-
-As a developer, don't do that. Read carefully the current documentation
-and, if you think it isn't sufficient for the utmost standards, please
-[make a PR](https://github.com/selfcustody/krux/pulls/new); it's a very
-`good first issue` and a welcomed contribution.
+Krux firmware is free and open-source software, built as a community effort.
+We welcome contributions of any kind: bug reports, feature requests, code,
+and documentation, from contributors of any experience level. We only ask
+that you respect others and follow the process described here.
 
 ---
 
-## Non `Krux` firmware contributions
-
-The `Krux` growth in the Bitcoin ecosystem is due to developments beyond firmware.
-They're built from real, material, and daily use cases from our beloved
-community of kruxers. While we love that, we cannot be responsible for any
-development made by our users.
+## Read the documentation
 
-Our developers and contributors are listed in both [krux contributors list](https://github.com/selfcustody/krux/contributors)
-and [krux-installer contributors list](https://github.com/selfcustody/krux-installer/contributors)
-.
+We maintain detailed
+[user documentation](https://selfcustody.github.io/krux). Please read it
+carefully before contributing. If you find it incomplete or unclear,
+improving it is a welcome contribution and a good first issue.
 
 ---
 
-## Communications Channels
+## Communication channels
 
-The primary communication channel is the [GitHub repository](https://github.com/selfcustody/krux)
-.
+The primary channel is the
+[GitHub repository](https://github.com/selfcustody/krux). Contributors are
+credited in the
+[krux](https://github.com/selfcustody/krux/contributors) and
+[krux-installer](https://github.com/selfcustody/krux-installer/contributors)
+contributor lists.
 
 ---
 
-## Contribution Workflow
-
-The contribution workflow is designed to facilitate cooperation and ensure a
-high level of quality in the project and not to enforce any type of dogmatic
-procedure on creative level. The process is as follows:
+## Contribution workflow
 
-To contribute a patch, the workflow is as follows:
+The workflow is meant to support cooperation and keep quality high, not to
+impose rigid procedure. To contribute a patch:
 
-  1. Fork Repository
-  2. Create topic branch
-  3. Commit patches
-  4. Push to fork
-  5. Open PR
-  6. Peer review
+  1. Fork the repository
+  2. Create a topic branch
+  3. Commit your changes
+  4. Push to your fork
+  5. Open a pull request
+  6. Address peer review
 
-### Fork Repository
+### Fork the repository
 
-[Fork the repository](https://github.com/selfcustody/krux), so you can create
-a remote repository fork for your changes. Then clone it:
+[Fork the repository](https://github.com/selfcustody/krux) and clone your
+fork:
 
 ```bash
 git clone git@github.com:<user>/krux.git
 ```
 
-Then follow the initial procedures described on [README.md](./README.md).
+Then follow the setup steps in [README.md](./README.md).
 
 ### Create a topic branch
 
-You always start with a `main` branch initialized. While the
-community of developers standardized this as the **stable** development branch
-(some projects could use the `master` branch for historical reasons),
-the `Krux` firmware team stated the first one as the **stable** branch and the
-`develop` as the branch that all developers should start from and experiment with.
-After you have had fun and discovered things, create a properly named branch to
-identify when we release:
-
-> Bitcoin related projects, like bdk, pdk and floresta use
-`<type>/<name>` named branches.
- 
+`main` is the stable branch and `develop` is the integration branch that all
+development starts from. Create your topic branch off `develop`, using a
+`<type>/<name>` convention (as used by Bitcoin projects such as bdk and
+floresta):
 
 ```bash
 main -> develop -> chore/task-stuff
                 -> ci/job-stuff
                 -> docs/info-new
-                ...
 ```
 
-So, in command line you could do this, keeping in mind what you will do in
-the PR:
-
 ```bash
-git checkout -b <type/name>
+git checkout develop
+git checkout -b <type>/<name>
 ```
 
-### Named branches
-
-A patch is a set of changes (patches or `diffs`) that you propose to `Krux`
-firmware developers to include in `develop` branch as a (set) of commits.
+### Commit your changes
 
-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 whenever possible, in order to ensure that `git bisect` and other automated tools
-function properly.
+Commits should be atomic and their diffs easy to read. Do not mix formatting
+changes or code moves with functional changes. Each commit should build and
+pass tests where possible, so that `git bisect` and other tools work
+reliably. New features should be covered by tests. When refactoring, keep
+pull requests focused and split large changes into smaller ones.
 
-When adding a new feature, ensure that it is covered by functional tests where
-possible. Avoiding this will create uncovered code.
-
-When refactoring, structure your PR to make it easy to review and don't
-hesitate to split it into multiple small, focused PRs.
-
----
-
-## Commit patches
-
-These [guidelines](https://chris.beams.io/posts/git-commit/) should be kept in
-mind. Commit messages follow the
+Follow these
+[commit message guidelines](https://chris.beams.io/posts/git-commit/) and 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.
-The types of commits we use are:
+specification. The commit types we use are:
 
-- `chore`: maintenance tasks (mostly lint, format);
+- `chore`: maintenance tasks (mostly lint and format);
 - `ci`: continuous integration (generally `.github/**` files);
 - `docs`: documentation changes (`*.md` files);
-- `feat`: new feature (`src/**`, imperatively -- it's recommended that `test` and
-  `docs` are accompanied in the PR);
-- `fix`: bug fix (see if it could break changes -- `!`, it's recommended that
-  `test` and `docs` are accompanied);
-- `git`: used when changing some git stuffs;
-- `i18n`: mostly addtion/fix of locale words/expressions;
-- `refactor`: code change that neither fixes a bug nor adds a feature (could be
-  a tiny change or a entire code-base refactor -- in krux refactor is the
-  first);
-- `style`: formatting, missing semi colons, ui colors, icons, etc; no functional
-  code change;
-- `test`: adding missing tests or correcting existing tests;
-
----
-
-## Push to fork
+- `feat`: new feature (`src/**`; tests and docs should accompany it);
+- `fix`: bug fix (use `!` for breaking changes; tests and docs should
+  accompany it);
+- `i18n`: addition or fix of locale strings;
+- `refactor`: change that neither fixes a bug nor adds a feature;
+- `style`: formatting, colors, icons, etc., with no functional change;
+- `test`: adding or correcting tests.
 
-With commits done, it's time to push to **your fork/branch:
+### Push to your fork
 
 ```bash
-# first time
-git push --set-upstream <user> <branch>
+# first push
+git push --set-upstream origin <branch>
 ```
 
----
-
-## Open PR
-
-After pushed to your fork/branch, github will show -- on your fork branch page --
-a button to Open PR. After click, you will be redirected to an editor with some
-templated structure. Fill the fields and open the PR. For WIP (Work In Progress)
-PRs we recommend to open a Draft PR.
+### Open a pull request
 
----
+After pushing, GitHub shows an "Open pull request" button on your fork's
+branch page. Fill in the template and open the PR against `develop`. For work
+in progress, open a Draft PR.
 
-## Peer review
+### Peer review
 
-To make sure our code has the highest quality and is maintainable for
-posterity, we have a thorough peer review process, where pull requests need
-to be reviewed by at least one maintainer, and must not have any outstanding
-comment from regular contributors (unless one of maintainers recognizes the
-rationale).
+To keep the codebase high quality and maintainable, every pull request is
+reviewed by at least one maintainer and should have no unresolved comments
+from contributors (unless a maintainer accepts the rationale).
 
-### Conceptual Review
+Reviews are expressed with acknowledgement (ACK) tags:
 
-A review can be a conceptual review, where the reviewer leaves a comment:
+- `cACK`: concept ACK, I agree with the goal of this PR;
+- `nACK`: I disagree with the change (must include a rationale; an
+  unexplained `nACK` may be disregarded);
+- `utACK`: untested ACK, I reviewed the code but did not test it;
+- `tACK`: tested ACK, I reviewed and tested the code.
 
-- Concept `cACK`: "I agree with the general goal of this pull request";
-- Approach `nACK`: "I do (not) agree with the approach of this change";
-- Untested `utACK`: "I didn't test, but ACK";
-- Tested `tACK`: "I tested and ACKed".
-
-A nACK needs to include a rationale why the change is not worthwhile.
-nACKs without accompanying reasoning may be disregarded.
-
-### Code Review
-
-After conceptual agreement on the change, code review can be provided.
-A review begins with ACK `BRANCH_COMMIT`, where `BRANCH_COMMIT` is the top of
-the PR branch, followed by a description of how the reviewer did the review.
-The following language is used within pull request comments:
-
-- Tested ACK:
-
-> tACK `babc00fe`. I have tested the code", involving change-specific manual
-testing and in case it was not obvious how the manual testing was done. nit:
-maybe it could be described in a `docs` commit sharing your intentions.
-
--- Untested ACK:
-
-> utACK `babc00fe`.
-"I have not tested the code, but I have reviewed it and it looks OK, I agree
-it can be merged".
-
-A "nit" refers to a trivial, often non-blocking issue.
-
-Project maintainers reserve the right to weigh the opinions of peer reviewers
-using common sense judgement and may also weigh based on merit. Reviewers that
-have demonstrated a deeper commitment and understanding of the project over
-time or who have clear domain expertise may naturally have more weight, as one
-would expect in all walks of life.
+A code review references the branch commit being reviewed. A "nit" is a
+trivial, usually non-blocking issue. For example:
 
 ```markdown
 tACK c00febab
 
-I liked the approach! Just some minor nit:
+I like the approach! One nit: line 3 has a typo in a comment,
+`Helllo` should be `Hello`:
 
-- the line 3 has a typo on comment: `Helllo` should be `Hello`. So 
-I suggest this change:
-
-<diff>
 - # The resulting Helllo
 + # The resulting Hello
-result = "Hello"
-</diff>
 
-Besides that, is a neat work @user!
+Nice work, @user!
 ```
 
+Maintainers weigh reviewer opinions using their judgement, giving more weight
+to reviewers with proven commitment or domain expertise.
+
 ---
 
-## Coding Conventions
+## Coding conventions
 
-There are a few rules to make sure the code is readable and maintainable.
-Most of them are checked by `poetry run poe lint` and `poetry run poe format`,
-and are enforced by CI.
+A few rules keep the code readable and maintainable. Most are checked by
+`poetry run poe lint` and `poetry run poe format`, and enforced by CI.
 
 ### Python
 
+Every source file starts with the license header:
+
 ```python
 # The MIT License (MIT)
 
 # Copyright (c) 2021-2026 Krux contributors
-
-# ...
-class Foo:
-    """Some awesome comment"""
-
-    def func(self):
-        """Some awesome comment"""
-        pass
 ```
 
-
-#### New features
-
-All new features require testing. Tests should be unique and self-describing.
-When it comes error handling, we prefer exact and meaningful error handling
-to deliver consumers (developers and users) an accurate error that describes
-exactly what happened wrong. Instead of:
+Prefer explicit, meaningful error handling that tells developers and users
+exactly what went wrong. Keep in mind that Krux runs on MicroPython. For
+example:
 
 ```python
-# A function that concatenate a int and a float into a str
-def foo(
-    bar: int,
-    baz: float,
-) -> str:
-    str(bar) + str(baz)
-```
-
-prefer:
-
-```python
-# A function that concatenate a int and a float into a str and why do that
-# for a good and reasonable reason that you should discuss with other developers
-# keep in mind that we're coding for micropython
 def foo(bar, baz):
-    """Serialize an int with a float into new str"""
+    """Serialize an int and a float into a new str"""
     if not isinstance(bar, int):
         raise ValueError("Expected bar to be an int")
 
     if not isinstance(baz, float):
         raise ValueError("Expected baz to be a float")
 
-    bar_str = str(bar)
-    baz_str = str(baz)
-
-    # We need to concatenate to be compliant
-    return bar_str + baz_str
+    return str(bar) + str(baz)
 ```
 
 ### Markdown
 
-Markdown files are linted too. This keeps the `*.md` files standardized and
-properly formatted for any code editor. Some of the currently applied rules
-enforced by CI:
+Markdown files are linted to stay consistent across editors. Some of the
+rules enforced by CI:
 
-```markdown
-- \# heading should be toplevel heading;
-- lines should be compact: 80 chars per line;
-- raw links aren't allowed, use the [text](link) format instead;
-- items should follow correct indentation.
-```
+- the first heading should be a top-level heading;
+- keep lines compact, around 80 characters;
+- use the `[text](link)` format instead of raw links;
+- follow correct list indentation.
 
 ---
 
 ## Testing
 
-We expect to have 95% test coverage for each PR. We have a few types of tests
-that you can run using `poetry run poe test`. See more with `poetry run poe`.
+We aim for high test coverage (95% or more) on each PR. Run the tests with
+`poetry run poe test`, and list all available tasks with `poetry run poe`.
 
 ---
 
 ## Release
 
-Once a maintainer and the contributors decide we have a stable enough `develop`
-with sufficient features, we will merge the `develop` branch with the `main`
-at that point. From this point, all new changes will go in the next release.
-After sufficient testing and making sure we don't have bugs left, this branch 
-will be released by one of the maintainers.
+When maintainers and contributors agree that `develop` is stable and has
+enough features, `develop` is merged into `main`. After further testing, a
+maintainer publishes the release.
 
-The release will have pre-built binaries available on github's asset page.
-They **must** be OpenSSL signed by [odudex](mailto:odudex@proton.me) --
-verifiable with [`selfcustody.pem`](./selfcustody.pem), and have a `zip`
-accompanied with `zip.sha256.txt` release assets.
+Releases include pre-built binaries on the GitHub assets page. They are
+OpenSSL signed by [odudex](mailto:odudex@proton.me) and verifiable with
+[`selfcustody.pem`](./selfcustody.pem), and ship as a `zip` accompanied by a
+`zip.sha256.txt` file.
 
-If we find bugs on a release, the fix may be backported and a new minor release
-may be released. This is done by merging fixes on top of the release branch.
-And then performing another release on that branch.
+If bugs are found in a release, fixes may be backported on top of the release
+branch and published as a new minor release.
 
-If you found any security issue, please read [`SECURITY.md`](https://github.com/selfcustody/krux/security),
-we're glad you have the choice to grow this community in a cypherpunk way.
+To report a security issue, please use the repository's
+[security advisories](https://github.com/selfcustody/krux/security).
 
-If you have any questions related to this process or the codebase in general,
-don't hesitate to reach out to us. We are happy to help newcomers in their
-amazing journey. Overall, have fun :)
+If you have questions about this process or the codebase, don't hesitate to
+reach out. We are happy to help newcomers. Have fun!