CHORE: Update missing or outdated files

[pyansys-automation]

The following files were added or updated:

• CODE_OF_CONDUCT.md file containing the contributor covenant code of conduct
• CONTRIBUTING.md file with contribution guidelines specific to the repository

Important

Replace {project-name} with the name of the project in the CONTRIBUTING.md file. For example, the project name for ansys/pymechanical is PyMechanical.

---

This pull request was created by a bot. If you have any questions, please ping the PyAnsys Core team for assistance. To ping the team write a comment in this issue with the following mention: @ansys/pyansys-core.

If you want this repository to be excluded from this automated maintenance process, please let us know by filling in the opt-out request form.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.97%. Comparing base (f127459) to head (de71793).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #911   +/-   ##
=======================================
  Coverage   94.97%   94.97%           
=======================================
  Files         110      110           
  Lines        5773     5773           
  Branches      296      296           
=======================================
  Hits         5483     5483           
  Misses        289      289           
  Partials        1        1           

Flag	Coverage Δ
direct-launch	92.20% <ø> (ø)
minimum-deps	93.07% <ø> (ø)
python-3.10	94.16% <ø> (ø)
python-3.11	94.09% <ø> (ø)
python-3.12	94.09% <ø> (ø)
python-3.13	94.33% <ø> (ø)
server-2024R2SP5	90.49% <ø> (ø)
server-2025R1SP4	94.12% <ø> (ø)
server-2025R2SP2	94.09% <ø> (ø)
server-2026R1	94.09% <ø> (ø)
server-latest	94.73% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[greschd]

@ansys/pyansys-core I think it would be useful for each updated file to be a separate PR. Here, the CODE_OF_CONDUCT.md can be merged easily, whereas CONTRIBUTING.md needs some more thought.

As for the CONTRIBUTING.md file:

• it would be useful to know how / why the file changed compared to the previous template version.
• we are currently including the main part of this file also in the Sphinx docs, delineated by <!-- START_MARKER_FOR_SPHINX_DOCS --> and <!-- END_MARKER_FOR_SPHINX_DOCS -->
  • I guess keeping those markers would mess with the automation checking this file?
  • are we meant to also replace / remove those sentences in the Sphinx docs?
• I think it might be useful for The following contribution information is specific to {project-name}. to go after the marker signaling the end of the common file, so that it could be reformulated e.g. to For contribution information specific to PyACP, refer to <link to the docs page>. Similarly for projects which don't have specific contributing guidelines, it would need to be reformulated or removed.

[RobPasMue]

Good feedback @greschd !

As to why we are submitting it as a full PR - it is mostly to minimize the number of PRs submitted. We've got both types of feedback in the past regarding this approach (submit a single PR with all changes -- vs -- submit individual PRs for each file).

Regarding the CONTRIBUTING.md file feedback, let's try to implement it @klmcadams.

• Point 1 (the how/why it has changed) would be part of the automation's repo git history, any decisions will be taken there. Automating this (i.e. letting end users nkow why it has changed) might be complicated for little benefit (you can simply see the changed files and ping us if there is something you don't agree with)
• We should ignore inline rST comments when checking against the file @klmcadams - if this is not done, let's do it.
• I like point 3 =) Let's try to do that too

[greschd]

would be part of the automation's repo git history, any decisions will be taken there

Might be good to simply link to that repo in the PR description? I think it's non-obvious if you don't already know where that is.

As for this specific change, I didn't find any additional info when looking at the maintenance repository. Specifically, would you adapt also the section in the rendered docs, or only the CONTRIBUTING.md?
I think our previous version was taken from the template repository (potentially quite some time ago), and then maybe edited during docs review.

[RobPasMue]

Might be good to simply link to that repo in the PR description? I think it's non-obvious if you don't already know where that is.

Ah - great idea! Let's add that as part of the body comment @klmcadams

As for this specific change, I didn't find any additional info when looking at the maintenance repository. Specifically, would you adapt also the section in the rendered docs, or only the CONTRIBUTING.md?
I think our previous version was taken from the template repository (potentially quite some time ago), and then maybe edited during docs review.

We were only targeting the content of the CONTRIBUTING.md file for now. If teams also render this information or something else on their documentation that's up to each team. I think your current online docs are a great source of content. But I would simply refer to them in the CONTRIBUTING.md file so that users have access to specific contributing guidelines for your repository.

We should revisit the template repo to make sure that both the automation repo and the template are aligned. That's also a good point. Let's track all this as an issue in the automation repo.

[klmcadams]

@greschd @RobPasMue For context, I was using this template for the CONTRIBUTING.md file since that's the one we refer to in the technical review: https://dev.docs.pyansys.com/packaging/structure.html#the-contributing-md-file

Could it make sense to append the CONTRIBUTING.md template to the top of the file rather than re-writing it, so it still keeps existing information?

[greschd]

Could it make sense to append the CONTRIBUTING.md template to the top of the file rather than re-writing it, so it still keeps existing information?

I think it's okay to rewrite.. if it differs significantly enough, it makes sense that there needs to be some manual intervention.

As a general escape hatch, is it possible to opt-out for specific files, or only globally (not that I'd want to opt out here)?

[klmcadams]

@greschd I believe right now it's only possible to opt out globally, but I think the option to opt out of specific files could be nice depending on the case @RobPasMue