updated documents and workflow to skip md updates

Author: maureeungaro

.github/workflows/codeql.yml

@@ -5,10 +5,16 @@ on:
     branches: [ "main" ]
     paths-ignore:
       - "**/README*"
+      - "**/CODE_OF_CONDUCT.md"
+      - "**/CONTRIBUTING.md"
+      - "**/SECURITY.md"
   pull_request:
     branches: [ "main" ]
     paths-ignore:
       - "**/README*"
+      - "**/CODE_OF_CONDUCT.md"
+      - "**/CONTRIBUTING.md"
+      - "**/SECURITY.md"
   schedule:
     - cron: '20 2 * * 5'
 

.github/workflows/dockers_deploy_and_test.yml

@@ -22,13 +22,19 @@ on:
   pull_request:
     paths-ignore:
       - "**/README*"
+      - "**/CODE_OF_CONDUCT.md"
+      - "**/CONTRIBUTING.md"
+      - "**/SECURITY.md"
   merge_group:
   push:
     branches: [ main ]
     tags: [ '*' ]
     paths-ignore:
       - "**/*.md"
       - "**/README*"
+      - "**/CODE_OF_CONDUCT.md"
+      - "**/CONTRIBUTING.md"
+      - "**/SECURITY.md"
       - "releases/**"
       - "doc/**"
 

.github/workflows/doxygen.yml

@@ -9,6 +9,9 @@ on:
       - '*'
     paths-ignore:
       - "**/README*"
+      - "**/CODE_OF_CONDUCT.md"
+      - "**/CONTRIBUTING.md"
+      - "**/SECURITY.md"
   workflow_dispatch:
 
 jobs:

.github/workflows/sanitize.yml

@@ -12,9 +12,15 @@ on:
     tags: [ 'v*' ]
     paths-ignore:
       - "**/README*"
+      - "**/CODE_OF_CONDUCT.md"
+      - "**/CONTRIBUTING.md"
+      - "**/SECURITY.md"
   pull_request:
     paths-ignore:
       - "**/README*"
+      - "**/CODE_OF_CONDUCT.md"
+      - "**/CONTRIBUTING.md"
+      - "**/SECURITY.md"
 
 jobs:
   discover:

CODE_OF_CONDUCT.md

@@ -1,50 +1,62 @@
 # GEMC Community Code of Conduct
 
 ## Our Pledge
-We, as members, contributors, and maintainers of GEMC, pledge to make participation 
-in our project and community a harassment-free experience for everyone, regardless of 
-age, body size, visible or invisible disability, ethnicity, experience level, 
-education, gender identity and expression, level of experience, nationality, personal 
-appearance, race, religion, or sexual identity and orientation.
+
+GEMC is a scientific software project. We want project spaces to be useful, respectful, and welcoming for everyone, regardless of age, body size, visible or invisible disability, ethnicity, experience level, education, gender identity and expression, nationality, personal appearance, race, religion, sexual identity and orientation, or any other personal characteristic.
 
 ## Our Standards
-Examples of behavior that contributes to a positive environment include:
-- Being respectful of differing viewpoints and experiences
-- Giving and gracefully accepting constructive feedback
-- Focusing on what is best for the community
-- Showing empathy and kindness to other community members
-
-Examples of unacceptable behavior include:
-- Harassment, intimidation, or discrimination
-- Trolling, insulting or derogatory comments, and personal or political attacks
-- Sexualized language or imagery
-- Public or private harassment, or publishing others’ private information
-- Sustained disruption of discussions or reviews
-- Spam or advertising unrelated to the project
 
-## Enforcement Responsibilities
-Project maintainers are responsible for clarifying and enforcing standards of acceptable 
-behavior and may take appropriate and fair corrective action in response to any behavior 
-they deem inappropriate, threatening, offensive, or harmful.
+Examples of behavior that helps the project:
+
+- Being respectful of different viewpoints and experiences.
+- Giving and accepting constructive technical feedback.
+- Focusing discussion on the work, evidence, and project goals.
+- Asking for clarification before assuming intent.
+- Helping new users and contributors find the right documentation, issue, or maintainer.
+
+Examples of unacceptable behavior:
+
+- Harassment, intimidation, discrimination, or threats.
+- Personal attacks, insults, trolling, or sustained disruption of discussions and reviews.
+- Sexualized language or imagery in project spaces.
+- Publishing private information without explicit permission.
+- Repeatedly ignoring maintainer requests to stop a behavior.
+- Spam, advertising, or unrelated promotion.
 
 ## Scope
-This Code of Conduct applies within all project spaces and also applies when an 
-individual is representing the project in public spaces.
+
+This Code of Conduct applies in all GEMC project spaces, including repositories, issues, pull requests, discussions, documentation, examples, release channels, and project-related meetings. It also applies when someone is representing GEMC in public spaces, such as conferences, workshops, mailing lists, or social platforms.
+
+## Enforcement Responsibilities
+
+Maintainers are responsible for clarifying standards and may remove, edit, or reject comments, commits, issues, pull requests, documentation, or other contributions that do not follow this Code of Conduct. Maintainers may also restrict participation when behavior is inappropriate, threatening, offensive, or harmful.
+
+Maintainers who are involved in a reported incident should not handle that report. An uninvolved maintainer or reviewer should be brought in.
 
 ## Reporting
-If you experience or witness unacceptable behavior, report it to **gemc@jlab.org**. 
-Reports will be reviewed and handled confidentially to the extent possible. 
-If the incident involves a maintainer, the project will bring in an uninvolved reviewer.
+
+Report Code of Conduct concerns to **ungaro@jlab.org**.
+
+Please include, when possible:
+
+- What happened and where it happened.
+- Links, screenshots, or other context.
+- Names or handles of people involved.
+- Whether the situation is ongoing or urgent.
+
+Reports will be handled confidentially to the extent possible. Retaliation against a person who reports a concern or participates in an investigation is itself a violation of this Code of Conduct.
 
 ## Enforcement
-All complaints will be reviewed and investigated promptly and fairly. 
-Maintainers are obligated to respect the privacy and security of the reporter of any incident.
 
-### Enforcement Guidelines
-- **Correction** — For minor, one-off issues. Consequence: private or public clarification of expectations.
-- **Warning** — For a single significant incident or repeated minor issues. Consequence: written warning and expectations for change.
-- **Temporary Restriction** — For repeated violations. Consequence: temporary removal from interactions (issues, PRs, etc.).
-- **Permanent Ban** — For severe or repeated violations. Consequence: permanent removal from community spaces.
+Maintainers will review reports promptly and fairly. Responses may include:
+
+- **Correction**: Private or public clarification of expectations.
+- **Warning**: Written warning and expectations for change.
+- **Temporary restriction**: Temporary removal from issues, pull requests, discussions, or other project spaces.
+- **Permanent restriction**: Permanent removal from project spaces for severe or repeated violations.
+
+The response will be based on the impact and severity of the behavior, the safety of the community, and any relevant pattern of prior conduct.
 
 ## Attribution
+
 This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1.

CONTRIBUTING.md

@@ -1,100 +1,90 @@
 # Contributing to GEMC
 
-We welcome contributions of code, documentation, tests, examples, and bug reports. This guide explains how to propose changes via GitHub.
+Contributions to GEMC are welcome. Useful contributions include source code, Python API improvements, documentation, examples, tests, bug reports, build-system fixes, and reproducible simulation problems.
 
-> **Quickstart**
-> 1. Open an issue to discuss your idea or bug.
-> 2. Fork the repo and clone your fork.
-> 3. Create a feature branch.
-> 4. Commit changes with clear messages and add tests/docs.
-> 5. Keep your fork in sync with `upstream`.
-> 6. Open a pull request (PR) from your branch.
+Keep changes focused and reviewable. A small pull request with clear motivation is easier to review and safer to merge than a broad rewrite.
 
----
+## Before You Start
 
-## 1) Before you start: open an issue
-Have a feature in mind? Open an issue describing the problem, proposed solution, and any alternatives. For obvious, small bug fixes, opening a PR directly is fine—but filing an issue first is still appreciated.
+Open an issue before working on large changes, new features, build-system changes, public APIs, file formats, or behavior that affects examples and documentation. Small typo fixes, narrow documentation edits, and obvious bug fixes can go directly to a pull request.
 
-If you’re not sure where to help, ask in an issue—documentation improvements are always welcome.
+For security vulnerabilities, do not open a public issue. Follow [`SECURITY.md`](SECURITY.md).
 
-## 2) Fork and clone
+## Development Setup
 
-Create your fork on GitHub, then:
+Fork `gemc/src` on GitHub, then clone your fork:
 
-```bash
-git clone https://github.com/<your-username>/src.git gemc
-cd gemc
-git remote add upstream https://github.com/gemc/src.git
-git remote -v
+```shell
+git clone https://github.com/<your-username>/src.git gemc-src
+cd gemc-src
 ```
 
-## 3) Create a branch
+## Build and Test
 
-Use a descriptive branch name:
+Use the project Meson build. The normal local command for building and installing the current tree is:
 
-```bash
-# Replace "main" with "master" if your fork uses that as the default
-git switch -c feature/my-awesome-idea
-# or: git checkout -b feature/my-awesome-idea
+```shell
+meson install -C build
 ```
 
-## 4) Keep your fork in sync
-Update your local default branch and your feature branch regularly:
+List available tests:
 
-```bash
-git fetch upstream
-git switch main
-git merge upstream/main    # or: git rebase upstream/main
-git push origin main
-
-# Update your feature branch
-git switch feature/my-awesome-idea
-git rebase main            # keeps history clean; use merge if you prefer
+```shell
+meson test -C build --list
 ```
 
-## 5) Code standards & tests
+Run the relevant test with logs:
+
+```shell
+meson test -C build -v --print-errorlogs <testname>
+```
 
-- **Style**: Match the existing project style. If a .clang-format/formatter is present, use it before committing.
-- **C++/Python APIs**: Keep naming, headers, and error handling consistent with the code around your changes.
-- **Tests**: Add or update tests for any behavior change.
-- **Docs**: Update README/installation/examples and any relevant docs when behavior or options change.
-- **Small, focused PR**s: Prefer multiple small PRs over one very large PR.
+When a change touches shared code, run the smallest useful set of related tests plus any examples that exercise the behavior. If a test cannot be run locally, say why in the pull request.
 
-## 6) Commit messages
+## Contribution Guidelines
 
-Write clear, imperative messages:
+- Match the style of the surrounding C++ or Python code.
+- Prefer clear, local fixes over broad refactors.
+- Add or update tests for behavior changes.
+- Update README files, examples, and website documentation when user-facing behavior changes.
+- Keep generated files, build output, caches, and local IDE files out of commits.
+- Do not mix unrelated cleanup with feature or bug-fix work.
+- For geometry or visualization changes, include screenshots or links to generated images when that helps review.
 
-```bash
+## Commit Messages
 
-Short summary (max ~72 chars)
+Use short, imperative commit summaries:
 
-Longer explanation of what and why,
-including any breaking changes or migration notes.
+```text
+Fix flux digitization timestamp output
 ```
 
-If your PR closes an issue, end the description with: Closes #<issue-number>.
+When the reasoning is not obvious, add a body explaining what changed and why. If the pull request closes an issue, include `Closes #123` in the pull request description.
+
+## Pull Requests
+
+Open a pull request from your fork to `gemc/src`.
+
+Before requesting review, check that:
 
-## 7) Open a Pull Request
-From your fork/branch, open a PR against gemc/source:
+- The title and description explain the change.
+- Related issues are linked.
+- Relevant tests or examples were run and listed.
+- Documentation and examples were updated if needed.
+- The pull request is focused on one topic.
 
-**Checklist**
+Reviews may ask for changes to improve correctness, maintainability, performance, documentation, or test coverage.
 
-- Clear title and concise description
-- Link to related issues; include Closes #123 when appropriate
-- Include screenshots for UI/visual changes
-- Tests pass locally; CI is green
-- Docs/examples updated as needed
+## Communication
 
-Reviews in this project are thorough. Feedback is offered in good spirit to improve clarity, performance, and maintainability.
+- General questions: open an issue.
+- Security vulnerabilities: email **ungaro@jlab.org** instead of opening a public issue.
+- Conduct concerns: email **ungaro@jlab.org** and see [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md).
 
-## 8) Communication & support
+## Licensing and Citation
 
-- Questions / help: Open an issue.
-- Security vulnerabilities: Do not open a public issue. Email gemc@jlab.org.
-- Conduct: All interactions are governed by our Code of Conduct.
+By contributing, you agree that your contributions are licensed under the GEMC Software License v1.0. See [`LICENSE.md`](LICENSE.md).
 
-## 9) Licensing of contributions
-By contributing, you agree that your contributions are licensed under the GEMC Software License v1.0 and 
-that publications using GEMC should cite:
+If you use GEMC in scientific work, cite:
 
-M. Ungaro, “Geant4 Monte-Carlo (GEMC) A database-driven simulation program,” EPJ Web of Conferences 295, 05005 (2024), https://doi.org/10.1051/epjconf/202429505005
+> M. Ungaro, "Geant4 Monte-Carlo (GEMC) A database-driven simulation program," EPJ Web of Conferences 295, 05005 (2024). https://doi.org/10.1051/epjconf/202429505005

README.md

@@ -144,7 +144,7 @@ Geometry scripts can write SQLite or ASCII databases, display geometry with PyVi
 
 PyVista is part of the normal GEMC geometry workflow. It lets users inspect detector geometry before running Geant4, export portable VTK.js scenes for documentation, and catch placement or rotation mistakes while editing Python geometry scripts.
 
-<!-- PyVista gallery setting: edit width="200" height="200" below to resize all thumbnails. -->
+<!-- PyVista gallery setting: edit width="300" height="300" below to resize all thumbnails. -->
 | B1 | B2 |
 | --- | --- |
 | <a href="https://gemc.github.io/home/assets/vtkjs-viewer.html?fileURL=https://gemc.github.io/home/assets/images/examples/b1/b1.vtksz"><img src="https://gemc.github.io/home/assets/images/examples/b1/geometry.png" alt="B1 PyVista geometry" width="300" height="300"></a> | <a href="https://gemc.github.io/home/assets/vtkjs-viewer.html?fileURL=https://gemc.github.io/home/assets/images/examples/b2/b2.vtksz"><img src="https://gemc.github.io/home/assets/images/examples/b2/geometry.png" alt="B2 PyVista geometry" width="300" height="300"></a> |