From c33026419a9b398c8d1e1df6473dc2d601c08b06 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pansanel?= Date: Sat, 7 Jun 2025 22:51:28 +0200 Subject: [PATCH 1/3] Add CONTRIBUTING file --- CONTRIBUTING.rst | 196 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 196 insertions(+) create mode 100644 CONTRIBUTING.rst diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst new file mode 100644 index 0000000..7a3dcf7 --- /dev/null +++ b/CONTRIBUTING.rst @@ -0,0 +1,196 @@ +Contributing to Mychem +====================== + +Thank you for taking the time to contriube to this project. +The maintainers greatly appreciate the interest of contributors +and rely on continued engagement with the community to ensure that +this project remains useful. +We would like to take steps to put contributos in the best possible +position to have their contributions accepted. +Please take a few moments to read this short guide on how to +contribute; bear in mind that contributions regarding how to best +contribute are also welcome. + +Feedback and Questions +---------------------- + +If you wish to discuss anything related to the project, please open an +issue on: https://github.com/mychem/mychem-code/issues. + +The maintainers will sometimes move closed issues off of GitHub to the +documentation if it make sens and could be benificial to a wider +community. + + +Kind of Contributions +--------------------- + +The maintainers recognise that contributions can be made in many forms, +depending on the skills, experience and perspectives of interested +parties. Contributions may come in the form of: + +- Feature or documentation requests, where they describe a need or gap + +- Authoring or review of releases + +- Direct authorship of code or documentation + +- Identifying and fixing bugs + + +Submitting Issues +----------------- + +Not every contribution comes in the form of code. Submitting, +confirming, and triaging issues is an important task for any project. +At Mychem we use GitHub to track all project issues. + + +Contribution Process +-------------------- + +Before proposing a contribution via pull request, please ensure that +an issue is open describing the need for your contribution. +You will need to refer to this issue number when you submit the pull +request. Please note: + +- It is recommended to make pull requests against release candidate + branches, whenever features are involved, in stead of against the + master branch. + +- Pull requests to the master branch can be made in the case obvious + fixes. + +We have a 3 step process for contributions: + +1. Fork the project if you have not, and commit changes to a git + branch + +2. Create a GitHub Pull Request for your change, following the + instructions in the pull request template. + +3. Perform a code review with the maintainers on the pull request. + + +Pull Request Requirements ++++++++++++++++++++++++++ + +1. Explain your contribution in plain language. To assist the + maintainers in understanding and appreciating your pull request, + please use the template to explain why you are making this + contribution, rather than just what the contribution entails. + +2. We expect tests to pass before peer review will begin. + + +Code Review Process ++++++++++++++++++++ + +Code review takes place in GitHub pull requests. +See `this article `_ +if you're not familiar with GitHub Pull Requests. + +Once you open a pull request, maintainers will review your code using +the built-in code review process in Github PRs. The process at this +point is as follows: + +1. A maintainer will review your code and merge it if no changes are + necessary. Your change will be merged into the repository's `master` + branch. + +2. If want your contribution to motivate your inclusion in the + authorship, please add a line to that effect in the pull request. + +3. If a maintainer has feedback or questions on your changes they + will set request changes in the review and provide an explanation. + + +Obvious Fix Policy +++++++++++++++++++ + +Small contributions, such as fixing spelling errors, where the content +is small enough to not be considered intellectual property can be made +against the master branch. + +As a rule of thumb, changes are obvious fixes if they do not introduce +any new functionality or creative thinking. Assuming the change does +not affect functionality, some common obvious fix examples include the +following: + +- Spelling / grammar fixes + +- Typo correction, white space and formatting changes + +- Comment clean up + +- Bug fixes that change default return values or error codes stored + in constants + +- Adding logging messages or debugging output + +- Changes to 'metadata' files like Gemfile, .gitignore, build scripts, + etc. + +- Moving source files from one directory or package to another + +**Note: whenever you invoke the "obvious fix" rule, please say so in +your commit message.** + + +Using git +--------- + +For collaboration purposes, it is best if you create a GitHub account +and fork the repository to your own account. Once you do this you will +be able to push your changes to your GitHub repository for others to +see and use, and it will be easier to send pull requests. + + +Branches and Commits +++++++++++++++++++++ + +You should submit your patch as a git branch named after the Github +issue, such as ``#3``. This is called a ``topic branch`` and allows users +to associate a branch of code with the ticket. + +It is a best practice to have your commit message have a summary +line that includes the ticket number, followed by an empty line and +then a brief description of the commit. This also helps other +contributors understand the purpose of changes to the code. + + +Release Cycle ++++++++++++++ + +We follow the `Semantic Versioning `_ as far as +applicable. This pattern says that software versions should take an +``X.Y.Z`` pattern where: + +- X is a major release, which may not be fully compatible with prior + major releases + +- Y is a minor release, which adds both new features and bug fixes + +- Z is a patch release, which adds just bug fixes + +Releases are generally performed after any bugfix / feature +enhancement pull request merge. You can watch the Github repository for +updates. +The latest release will always point to the master branch, while +release candidates will be done in version-specific branches, such as +``v0.2.0-rc``. + + +Publishing Releases ++++++++++++++++++++ + +Major releases are published in Zenodo, using the GitHub integration. +The ``codemeta.json`` file must be updated prior to each release, +accurately describing the research object, and properly recognising +author and contributor metadata. + + +Acknowledmegent +--------------- + +This file has been modified from the Chef Cookbook Contributing Guide. From a3e5613622a4415c1b07dae5beaee1d860cfae99 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pansanel?= Date: Sat, 7 Jun 2025 23:04:33 +0200 Subject: [PATCH 2/3] Add the Mychem CODE_OF_CONDUCT --- CODE_OF_CONDUCT.rst | 152 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 CODE_OF_CONDUCT.rst diff --git a/CODE_OF_CONDUCT.rst b/CODE_OF_CONDUCT.rst new file mode 100644 index 0000000..23c1e40 --- /dev/null +++ b/CODE_OF_CONDUCT.rst @@ -0,0 +1,152 @@ +Mychem Code of Conduct +====================== + +Our Pledge +---------- + +We as members, contributors, and leaders pledge to make participation +in our community a harassment-free experience for everyone, regardless +of age, body size, visible or invisible disability, ethnicity, sex +characteristics, gender identity and expression, level of experience, +education, socio-economic status, nationality, personal appearance, +race, caste, color, religion, or sexual identity and orientation. + +We pledge to act and interact in ways that contribute to an open, +welcoming, diverse, inclusive, and healthy community. + + +Our Standards +------------- + +Examples of behavior that contributes to a positive environment for our +community include: + +- Demonstrating empathy and kindness toward other people + +- Being respectful of differing opinions, viewpoints, and experiences + +- Giving and gracefully accepting constructive feedback + +- Accepting responsibility and apologizing to those affected by our + mistakes, and learning from the experience + +- Focusing on what is best not just for us as individuals, but for the + overall community + +Examples of unacceptable behavior include: + +- The use of sexualized language or imagery, and sexual attention or + advances of any kind + +- Trolling, insulting or derogatory comments, and personal or political + attacks + +- Public or private harassment + +- Publishing others’ private information, such as a physical or email + address, without their explicit permission + +- Other conduct which could reasonably be considered inappropriate in a + professional setting + + +Enforcement Responsibilities +---------------------------- + +Community leaders are responsible for clarifying and enforcing our +standards of acceptable behavior and will take appropriate and fair +corrective action in response to any behavior that they deem +inappropriate, threatening, offensive, or harmful. + +Community leaders have the right and responsibility to remove, edit, or +reject comments, commits, code, wiki edits, issues, and other +contributions that are not aligned to this Code of Conduct, and will +communicate reasons for moderation decisions when appropriate. + + +Scope +----- + +This Code of Conduct applies within all Mychem community spaces, and +also applies when an individual is officially representing the Mychem +community in public spaces. Examples of representing our community +include using an official email address, posting via an official social +media account, or acting as an appointed representative at an online or +offline event. + + +Enforcement +----------- + +Instances of abusive, harassing, or otherwise unacceptable behavior may +be reported to the community leaders responsible for enforcement at +jerome.pansanel@iphc.cnrs.fr. All complaints will be reviewed and +investigated promptly and fairly. + +All community leaders are obligated to respect the privacy and security +of the reporter of any incident. + + +Enforcement Guidelines +---------------------- + +Community leaders will follow these Community Impact Guidelines in +determining the consequences for any action they deem in violation of +this Code of Conduct: + +1. Correction ++++++++++++++ + +**Community Impact**: Use of inappropriate language or other behavior +deemed unprofessional or unwelcome in the community. + +**Consequence**: A private, written warning from community leaders, +providing clarity around the nature of the violation and an explanation +of why the behavior was inappropriate. A public apology may be +requested. + +2. Warning +++++++++++ + +**Community Impact**: A violation through a single incident or series of +actions. + +**Consequence**: A warning with consequences for continued behavior. No +interaction with the people involved, including unsolicited interaction +with those enforcing the Code of Conduct, for a specified period of +time. This includes avoiding interactions in community spaces as well as +external channels like social media. Violating these terms may lead to a +temporary or permanent ban. + +3. Temporary Ban +++++++++++++++++ + +**Community Impact**: A serious violation of community standards, +including sustained inappropriate behavior. + +**Consequence**: A temporary ban from any sort of interaction or public +communication with the community for a specified period of time. No +public or private interaction with the people involved, including +unsolicited interaction with those enforcing the Code of Conduct, is +allowed during this period. Violating these terms may lead to a +permanent ban. + +4. Permanent Ban +++++++++++++++++ + +**Community Impact**: Demonstrating a pattern of violation of community +standards, including sustained inappropriate behavior, harassment of an +individual, or aggression toward or disparagement of classes of +individuals. + +**Consequence**: A permanent ban from any sort of public interaction +within the community. + + +Attribution +----------- + +This Code of Conduct is adapted from the `Contributor +Covenant `__, version 2.1, +available at +https://www.contributor-covenant.org/version/2/1/code_of_conduct.html. From c9d30708e07e3221b84acd82f34e70ad601fc92a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pansanel?= Date: Sat, 7 Jun 2025 23:06:10 +0200 Subject: [PATCH 3/3] Remove Ubuntu 20.04 checks --- .github/workflows/cmake-multi-platform.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/cmake-multi-platform.yml b/.github/workflows/cmake-multi-platform.yml index b25eeb2..690a812 100644 --- a/.github/workflows/cmake-multi-platform.yml +++ b/.github/workflows/cmake-multi-platform.yml @@ -22,7 +22,7 @@ jobs: # To add more build types (Release, Debug, RelWithDebInfo, etc.) # customize the build_type list. matrix: - os: [ubuntu-20.04,ubuntu-22.04,ubuntu-24.04] + os: [ubuntu-22.04,ubuntu-24.04] build_type: [Release] c_compiler: [gcc] cpp_compiler: [g++]