Updated Contributing

ZhukMax · ZhukMax · commit b049511299fa · 2025-10-13T23:21:44.000+02:00
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,61 +1,84 @@
 # Contributing to EFx
 
-Thank you for your interest in contributing!
+[![PRs Welcome](https://img.shields.io/badge/PullRequest-welcome-brightgreen.svg?style=flat-square)]()
+
+Thank you for your interest in contributing!  
 Any help — from filing a bug report to implementing new tags — makes EFx better.
 
 ---
 
-## Principles
+## 🧭 Principles
 
-* **Safety & compatibility.** Avoid breaking public APIs unless agreed upon in advance.
-* **Code style.** Follow `cargo fmt` and ensure `clippy` passes without warnings.
-* **Tests.** Any logic change should come with tests (`cargo test`, doctests, compile-fail tests).
+* **Safety & compatibility.** Avoid breaking public APIs unless discussed in advance.
+* **Code style.** Follow `cargo fmt`; ensure `clippy` passes without warnings.
+* **Tests.** Any logic change should include tests (`cargo test`, doctests, compile-fail tests).
 * **Docs.** Public APIs, new tags, and attributes must be documented.
 * **Performance.** Avoid regressions; add profiling notes if relevant.
 
 ---
 
-## Filing Issues
+## 🐞 Filing Issues
 
 Before opening a new issue:
 
 1. **Search existing issues** to avoid duplicates.
-2. Prepare a **minimal reproducible example** (short `efx! { ... }` snippet, log, or screenshot).
+2. Prepare a **minimal reproducible example** — short `efx! { ... }` snippet, log, or screenshot.
+3. For new features, provide a **short rationale** or reference an RFC.
 
-**Template for issues:**
+**Issue template:**
 
-* **Type:** bug / feature / docs / question
-* **Expected behavior:** …
-* **Actual behavior:** …
-* **Reproduction:** code or steps
-* **Versions:** `rustc --version`, EFx crate versions
-* **Platform:** OS/architecture
+* **Type:** bug / feature / docs / question  
+* **Expected behavior:** …  
+* **Actual behavior:** …  
+* **Reproduction:** code or steps  
+* **Versions:** `rustc --version`, EFx crate versions  
+* **Platform:** OS/architecture  
 * **Additional info:** backtrace, perf data, etc.
 
+> 💡 *Tip:* issues labeled `good first issue` are designed for first-time contributors.
+
+---
+
+## 🧩 Workflow Overview
+
+### 1. Pick or propose an issue
+
+* **Claim an issue:** comment “I’d like to take this” (optionally with a short plan/ETA).  
+  The maintainer will assign it to you.  
+* **Propose a new issue:** open a ticket as described above.  
+  If relevant, start from the roadmap RFC:  
+  [`EFX-0001`](efx/docs/rfcs/EFX-0001-roadmap-0.5-0.7.md).
+
 ---
 
-## Submitting Pull Requests
+### 2. Fork & branch
+
+Fork the repository and create a **feature branch from `main`**:
 
-1. **Fork** and create a branch:
+```bash
+git checkout main
+git pull
+git checkout -b feat/short-topic
+````
 
-    * `feat/<feature>` — new functionality
-    * `fix/<bug>` — bugfix
-    * `docs/<topic>` — docs only
-    * `chore/<topic>` — maintenance
-2. Make your changes and ensure **all tests pass**.
-3. Update **docs** and **CHANGELOG.md** if behavior is user-visible.
-4. Run local checks (see below).
-5. Open a PR with:
+Keep your branch focused on **one issue**.
 
-    * **Title:** short and clear
-    * **Description:** what/why, how tested, API impact
-    * Link to relevant **issue or RFC**
+Branch naming convention:
 
-Small follow-up commits for review fixes are welcome.
+| Type     | Example               | Purpose                   |
+|----------|-----------------------|---------------------------|
+| `feat/`  | `feat/button-rounded` | New feature or tag        |
+| `fix/`   | `fix/text-alignment`  | Bugfix                    |
+| `docs/`  | `docs/taglist-update` | Documentation             |
+| `chore/` | `chore/ci-cache`      | Maintenance or CI updates |
 
 ---
 
-## Pre-PR Checklist
+### 3. Implement with tests & docs
+
+Make your changes and ensure **all tests and examples build**.
+
+Local checks:
 
 ```bash
 # formatting
@@ -64,43 +87,72 @@ cargo fmt --all -- --check
 # linting
 cargo clippy --all-targets --all-features -D warnings
 
-# tests (unit, doctests, compile-fail)
+# tests
 cargo test --workspace
 
-# docs build
+# docs
 cargo doc --workspace --no-deps
 ```
 
-You can also check examples manually:
+Examples (build-only; GUI run is not required):
 
 ```bash
-cargo run -p efx-sandbox
-cargo run -p efx --example eframe_demo
+cargo build -p efx --example eframe_demo --locked
+rustup target add wasm32-unknown-unknown
+cargo build -p efx --example eframe_demo --target wasm32-unknown-unknown --locked
 ```
 
 ---
 
-## Commit Messages
+### 4. Open a Pull Request
+
+* Target the **next release branch** (e.g. `v0.6`, `v0.7`).
+  If the issue has a **milestone**, use the branch named after it.
+* Link the issue (e.g. `Closes #123`) and fill in the PR checklist.
 
-Use [Conventional Commits](https://www.conventionalcommits.org/):
+**PR checklist:**
+
+* [ ] References related issue / RFC section when behavior changes
+* [ ] CI is green (workspace + examples + wasm32 build)
+* [ ] Tests/docs updated where applicable
+* [ ] No unrelated changes
+
+**PR title examples (Conventional Commits):**
 
 ```
 feat(button): add rounding attribute
 fix(core): correct parsing of numeric attribute
 docs: update intro example
 ```
 
+Small review-fix commits are welcome.
+
+---
+
+### 5. Reviews & merge
+
+* Review comments should be addressed promptly.
+* Smaller, focused PRs get merged faster.
+* If you go silent for **7 days**, the issue may be unassigned to keep momentum (you can re-claim it anytime).
+
+---
+
+## 🧪 Versioning
+
+We follow **Semantic Versioning (SemVer)**.
+Breaking changes require prior discussion in an issue or RFC.
+All user-facing changes must be added to `CHANGELOG.md` under **Unreleased**.
+
 ---
 
-## Versioning
+## ⚖️ License
 
-We follow **SemVer**.
-Breaking changes require discussion in an issue/RFC.
-All user-facing changes should be added to `CHANGELOG.md` under **Unreleased**.
+By submitting a contribution, you agree that your work is licensed under the same terms as EFx —
+[MIT or Apache-2.0](efx/LICENSE).
 
 ---
 
-## License
+## 💬 Contact
 
-By submitting a contribution, you agree that your work is licensed under the same terms as EFx
-([MIT OR Apache-2.0](efx/LICENSE)).
+Questions, clarifications, or coordination requests:
+📧 [mail@zhukmax.com](mailto:mail@zhukmax.com)
diff --git a/README.md b/README.md
@@ -1,4 +1,4 @@
-![EFX — Rust templating for egui/eframe](efx/docs/efx_cover.png)
+![EFX — Rust templating for egui/eframe](https://github.com/ZhukMax/efx/raw/main/efx/docs/efx_cover.png)
 
 # EFx
 [![Crates.io](https://img.shields.io/crates/v/efx.svg?color=green)](https://crates.io/crates/efx)
@@ -37,7 +37,7 @@ use efx::efx; // the macro
 ---
 
 ### Documentation
-You can see on web page https://docs.rs/efx/latest/efx/ or in files:
+You can see on web page https://docs.rs/efx or in files:
 
 - [Introduction](efx/docs/intro.md) ([🇫🇷 fr](efx/docs/fr/intro.md))
 - [Tags](efx/docs/tags.md) ([🇫🇷 fr](efx/docs/fr/tags.md))
@@ -176,65 +176,13 @@ Use the example in `examples/winit_wgpu_min.rs` as a starting point.
 
 ---
 
-### Contributing
+### 🤝 Contributing
 
-[![PRs Welcome](https://img.shields.io/badge/PullRequest-welcome-brightgreen.svg?style=flat-square)]()
-
-**Thanks for considering a contribution!** Please follow this lightweight workflow:
-
-#### 1) Pick or propose an issue
-
-* **Claim an issue:** comment “I’d like to take this” (optionally add a brief plan/ETA).
-  The maintainer will assign it to you.
-* **Propose a new issue:** open a ticket with a minimal reproducible example (for bugs) or a short rationale (for features).
-  Start with the roadmap RFC: [EFX-0001](efx/docs/rfcs/EFX-0001-roadmap-0.5-0.7.md).
-
-> Tip: issues labeled `good first issue` are designed for first-time contributors.
-
-#### 2) Fork & branch
-
-* Fork the repository and create a **feature branch from `main`**:
-
-  ```bash
-  git checkout main
-  git pull
-  git checkout -b feat/short-topic
-  ```
-* Keep your branch focused on **one issue**.
-
-#### 3) Implement with tests & docs
-
-* Make the change and add tests/docs where it makes sense.
-* Local checks (examples build-only; no GUI run is required):
-
-  ```bash
-  cargo fmt --all
-  cargo clippy --all-targets -- -D warnings
-  cargo build --workspace --locked
-  cargo build -p efx --example eframe_demo --locked
-  rustup target add wasm32-unknown-unknown
-  cargo build -p efx --example eframe_demo --target wasm32-unknown-unknown --locked
-  ```
-
-#### 4) Open a Pull Request
-
-* Target the **next release branch** (e.g., `v0.6`, `v0.7`).
-  If the issue has a **milestone**, use the branch named after that milestone.
-* Link the issue (e.g., “Closes #123”) and fill the checklist below.
-
-**PR checklist**
-
-* [ ] References the related issue / RFC section when behavior changes.
-* [ ] CI is green (workspace build, examples, wasm32 build-only).
-* [ ] Tests/docs updated where applicable.
-* [ ] No unrelated changes.
-
-#### 5) Reviews & merge
-
-* Address review comments; small, focused PRs get merged faster.
-* If you go silent for **7 days**, the issue may be unassigned to keep momentum (you can re-claim it anytime).
-
-**Questions?** Reach out at [mail@zhukmax.com](mailto:mail@zhukmax.com).
+We welcome contributions from the community!  
+Please read our [Contributing Guide](./CONTRIBUTING.md) for details on:
+- branching and PR rules,
+- issue creation and discussion process,
+- coding conventions and CI requirements.
 
 ---
 
