Project approval and public release#
Most of the projects in PyAnsys expose the functionality of Ansys products. Due to intellectual property reasons, the public release of a PyAnsys library must go through a project approval process.
To trigger the public release process, project leads must fill in this form:
The form lets the different parties involved in the public release process know that there is a request to release a project. If your intent is to release an Ansys Open Source project, then continue to the next section.
The approval process is divided into three parts:
An approval from each of these three parts is required to release a project to the public.
Once approved, a project can be published to the Public PyPI.
When releasing a project to the public, you should:
Coordinate with the product line development team, if applicable.
Maintain the project by means of fixing bugs and providing support for new releases.
Uphold Ansys’ reputation in the open source community.
Once all three approvals have been awarded, project leads must complete the next form:
This form serves as a final checklist to verify that all approvals have been processed and to formalize the OSS approval process as a final record. You can find frequently asked questions in Questions asked in the OSS approval request form.
The managerial part of the approval process ensures that the direct manager, general managers, vice presidents, or the chief technology officer are aware of the project’s existence and status.
A project must be classified into one of these categories, determining the number of administrative reviews and approvals needed:
Documentation projects must have direct manager approval, legal review, and documentation proofing. No source code other than documentation files is allowed.
Tool projects require direct manager and business unit’s general manager approval. No product source code is allowed.
Library projects interfacing and wrapping any Ansys products require approval from the direct manager, product line, and the chief technology officer. No product source code is allowed.
Legal review approval ensures that the entire project complies with Ansys’ legal policies.
Start by completing the legal review request form for open sourcing the code:
The following checks are required when performing the legal review of the project:
The project has the correct license.
The contribution does not contain any strong encryption.
Ansys official logos and branding images are used in the project.
The Ansys copyright appears in the correct location as required by the Legal department.
The copyright has the proper formatting, which is
Copyright (C) YYYY ANSYS, Inc..
The contribution does not embody any unapproved Ansys intellectual property for open sourcing.
The contribution does not embody any inventions for which Ansys has sought or received patent protection.
Any third-party open source code included in the contribution has been reviewed for security vulnerabilities and includes their license files in the repository.
Open source dependencies not distributed as part of the project do not need
their licenses included in the Ansys repository. Examples include dependent
Node Package Manager (
npm) modules or Python packages from PyPI.
Technical approval ensures that the project follows the best and latest software development practices. Request a technical review by sending an email to email@example.com.
The technical review of the project verifies the following:
The project name follows naming conventions.
The project version follows Semantic versioning.
The project author is ANSYS, Inc.
The project maintainer is ANSYS, Inc.
Contact and support information is provided in the project.
The AUTHORS file is present and compliant with legal requirements.
The LICENSE file is present and compliant with legal requirements.
The CONTRIBUTING.md file is present.
The CONTRIBUTORS.md file is present and contains the project lead and main contributors.
The project layout follows the Packaging style guidelines.
Testing guarantees at least 80% code coverage.
The project adheres to the Documentation style guidelines.
The source code docstring examples have been tested.
The documentation examples are presented as a gallery.
The documentation receives the documentation team’s approval.
The package builds properly.
The project uses CI/CD, including all the Required workflows.
The CI/CD pipeline generates project Artifacts.
Questions asked in the OSS approval request form#
When filling in the OSS approval request form, project leads must supply responses to several types of questions:
What is the name of your project?
Who is the project maintainer?
Who is the lead from the product team?
Who is the Product Management contact?
Who is the ACE/AFT owner?
Who validated your legal readiness?
Provided there are no issues with the MIT license, have you correctly applied it to the GitHub Repository for your project?
Is the copyright header correctly applied to your files in GitHub?
Have you confirmed that any intellectual property is removed from the code, docs, and examples?
I and my legal reviewer, as well as my product and PM reviewer, have confirmed that there is no business interest in keeping this code confidential.
I and my legal reviewer confirm there is no business interest in enforcing copyright protection for this code.
I and my legal reviewer confirm that the code does not contain any third-party material (open source, proprietary, partner, customer, or otherwise).
I and my legal reviewer confirm that the code does not include any invention on which the company has, or might want to seek, a patent.
Have you cleaned up comments, issues, and pull requests to remove any potentially bad content?
My legal reviewer and I have checked the dependencies and validated that they do not impose any licensing difficulties.
I and my legal reviewer confirm there is NO encryption present in the code.
The repository that hosts the code is generally accessible to the public with no time limits or access restrictions.
This tool or library is not meant for use in any specific industry, platform, or process but rather for use by general customers.
Who verified your technical review?
Has your library documentation been reviewed by a documentation team member?
Has your source code documentation been reviewed by a developer team member?
Has end user testing been completed?
Has CI/CD testing been implemented?
Has a minimum test coverage of 80% been achieved?
Are usage and installation examples included and tested?
Is the package definition ready and PyPi packaging completed?
Does the GitHub repository supply contribution guidance and have CLA set up?
Who on the Product Marketing Manager (PMM) or Developer Ecosystem (DevEco) team checked your project for readiness?
Did you tell ACE and your Business Unit lead that you are ready for release?
Is there something public that already has the same name as your project?
Did you get PMM signoff?
Did you ask the DevEco team to update links from the Developer Portal to your new OSS project?
Did you let the PMM team know that your library is nearing release?