Merge pull request #77 from C4dynamics/dev

1. simplify the contributing.md. 2. move the pdf paper to the paper f…

Author: c4dynamics

.github/workflows/paper.yml

@@ -21,7 +21,7 @@ jobs:
           # This is the output path where Pandoc will write the compiled
           # PDF. Note, this should be the same directory as the input
           # paper.md
-          path: paper/paper.pdf
+          path: paper/*.pdf
 
 
 

contributing.md

@@ -1,57 +1,81 @@
-
 # Quickstart for Contributors 🚀
 
-The best way to contribute to c4dynamics is by providing a well-documented use case notebook in the [Use Cases section](https://c4dynamics.github.io/C4dynamics/programs/index.html) of the documentation.
-These notebooks help other engineers quickly understand how to apply the framework in practice.
-
---- 
-## How to Add a Use Case Notebook
-
-* Fork the repository (top-right corner of the GitHub page)
-* Design your model or algorithm simulation
-* Build with state objects 
-* Extend with modules from the scientific library (e.g. sensors, filters, detectors)
-* Write your program in a Jupyter notebook  
-    - Keep it simple yet functional
-    - Add comments and documentation to explain your approach
-    - Test thoroughly: make sure it runs without errors and produces meaningful results
-    - Visualize outputs: use c4dynamics tools 
-
---- 
-## New Features and Features Modifications 
-
-If you come up with an idea for a new function or capability, please open an issue first so it can be discussed. Once agreed, you can start working on it in a separate scope. However, any change to the c4dynamics module requires following c4dynamics standards:
-
-* Coding
-    - PEP8-adjacent: Follow Python conventions (imports at the top, clear indentation, type hints with Optional)
-    - NumPy-based math: Use np.atleast_1d, np.atleast_2d, and standard linear algebra structures
-    - Defensive coding: Check for None values, enforce shapes (np.atleast_2d), raise errors (TypeError) for invalid argument combinations
-
-* Commenting 
-    - Extensive docstrings (triple quotes inside class and methods):
-        + Follow the NumPy docstring standard
-        + Include doctest-style code snippets inside the docstrings for demonstration and validation
-        + Provide references to related modules/classes (cross-referencing using `:class:` and `:mod:`)
-    - Inline comments:
-        + Short, pragmatic explanations inside functions 
-        + Not verbose, just clarifies tricky implementation details
-
-* Testing 
-    - Doctest-first:
-        + The examples inside the docstrings use also as test cases, runnable via `doctest.testmod()`
-        + Use doctest options like +NUMPY_FORMAT to ignore formatting variations in arrays
-    - Self-contained testing block:
-        + Wrapped in if `__name__ == "__main__"`:, so tests can be run simply by executing the file.
-    - Results are either printed to console (`cprint`) or redirected to a log file.
-    - Use `FAIL_FAST` so tests stop at the first failure
-
-
-Once your changes are ready, submit your version: 
-
-* Fork the repository (top-right corner of the GitHub page)
-* Add comments and documentation to explain your approach
-* Add docstring examples and tests in the dedicated unittest files
-* Test thoroughly: make sure it runs without errors and produces meaningful results
-* Run the doctests locally. Run: ```python tests/run_doctests.py``` 
-* Run the unit tests locally. Run: ```python tests/run_unittests.py```
+Welcome! Whether it’s your first contribution or you’re an experienced engineer, this guide will help you contribute to **c4dynamics**.
+
+We mainly accept contributions in two areas:
+
+1. **Use Case Notebooks** – Practical examples demonstrating framework usage.
+2. **New Features / Feature Modifications** – Extensions or improvements to the framework itself.
+
+---
+
+## 1️⃣ Use Case Notebook
+
+The best way to contribute to c4dynamics is by providing a well-documented use case notebook in the [Use Cases section](https://c4dynamics.github.io/C4dynamics/programs/index.html) of the documentation. 
+
+These notebooks help engineers quickly understand how to apply **c4dynamics** in practice.
+
+### steps: 
+
+1. **Fork the repository** (top-right corner on GitHub).
+2. **Set up your environment** (install dependencies, etc.).
+3. **Design your model or algorithm simulation.**
+4. **Build using state objects** and extend with modules from the scientific library (e.g., sensors, filters, detectors).
+5. **Write your program in a Jupyter notebook.**
+
+   * Keep it simple yet functional.
+   * Add comments and documentation to explain your approach.
+6. **Test thoroughly:** Ensure it runs without errors and produces meaningful results.
+7. **Visualize outputs** using **c4dynamics** tools.
+8. **Submit your contribution**:
+
+   * Add your notebook to the `Use Cases` section of the documentation.
+   * Include any comments, explanations, and docstring examples.
+
+---
+
+## 2️⃣ New Features or Modifying Existing Ones
+
+If you have an idea for a new function or feature:
+
+1. **Open an issue first** to discuss the proposal.
+2. Once approved, **work in a separate feature branch**.
+
+### Coding Standards
+
+* **Follow Python conventions** (PEP8-adjacent).
+* **Use NumPy-based math:** `np.atleast_1d`, `np.atleast_2d`, standard linear algebra structures.
+* **Defensive coding:** Check for `None`, enforce shapes, raise `TypeError` for invalid arguments.
+
+### Commenting & Documentation
+
+* **Docstrings:** Use triple quotes, follow NumPy style, include doctest examples, reference related modules/classes.
+* **Inline comments:** Short, clear explanations of tricky code parts.
+
+### Testing
+
+* **Doctests:** Include examples inside docstrings. Run via `doctest.testmod()`.
+* **Self-contained testing block:** Wrap in `if __name__ == "__main__":`.
+* **Unit tests:** Add tests to the dedicated unittest files.
+* **Run tests locally:**
+
+  ```bash
+  python tests/run_doctests.py
+  python tests/run_unittests.py
+  ```
+
+### Submitting Changes
+
+1. Fork the repository (if not already done).
+2. Commit your changes with clear messages.
+3. Push your feature branch.
+4. Open a Pull Request (PR) for review.
+
+---
+
+## ✅ Tips for First-Time Contributors
+
+* Start with a small **use case notebook** to get familiar with the framework.
+* Don’t worry about perfection—your contribution will be reviewed and improved collaboratively.
+* Read the examples in existing notebooks to see formatting and documentation standards.