You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I came up with the following guidelines which I am planning to add (somewhere) in the future. Leaving them here as reference in the meantime
Facilitating contributions in the form of examples
One of the main challenges we face inside our libraries is the lack of examples. Examples are
critical for users to understand how to use the library and present new functionality. They are also
a great mechanism to educate users on the best practices of using it.
When users want to contribute examples, we need to make it as easy as possible for them to do so. This
means that we need to provide a clear structure for them to follow. We also need to make sure that the
build process is as simple as possible.
3 best practices for examples are:
Providing a template: This is a great way to ensure that users follow the same structure. It also makes it easy for
them to get started. The template should include all the necessary information, such as the name of the
example, a description, and the code itself.
Verifying the example: This is a great way to ensure that the example works as expected. It also helps to catch any
errors before they are submitted. The verification process should include running the example and checking
the output. If the example fails, it should be easy for the user to fix it.
Templates
Here an example on how to promote the use of templates for examples:
The verification process will depend on each library and the tools used for generating the examples. Within
our ecosystem, we are using Sphinx Gallery and NBSphinx to generate the examples, and the build process
is slightly different for each library.
However, the following approach could be useful for all libraries:
Create a Makefile target that only runs a specific example.
This target should be used to run the example and check the output. If the example fails, it should be easy for the user to fix it.
An example of this is the make target in PyAnsys Geometry:
make single-example examples/01_getting_started/01_math.mystnb
The pull request in which this was added is: ansys/pyansys-geometry#1893
This implementation is specific for NB Sphinx, but the idea is to create a target that runs a specific example and checks the output.
The text was updated successfully, but these errors were encountered:
I came up with the following guidelines which I am planning to add (somewhere) in the future. Leaving them here as reference in the meantime
Facilitating contributions in the form of examples
One of the main challenges we face inside our libraries is the lack of examples. Examples are
critical for users to understand how to use the library and present new functionality. They are also
a great mechanism to educate users on the best practices of using it.
When users want to contribute examples, we need to make it as easy as possible for them to do so. This
means that we need to provide a clear structure for them to follow. We also need to make sure that the
build process is as simple as possible.
3 best practices for examples are:
them to get started. The template should include all the necessary information, such as the name of the
example, a description, and the code itself.
errors before they are submitted. The verification process should include running the example and checking
the output. If the example fails, it should be easy for the user to fix it.
Templates
Here an example on how to promote the use of templates for examples:
These templates are also referred to in the contributing guidelines.
Verifying examples
The verification process will depend on each library and the tools used for generating the examples. Within
our ecosystem, we are using Sphinx Gallery and NBSphinx to generate the examples, and the build process
is slightly different for each library.
However, the following approach could be useful for all libraries:
This target should be used to run the example and check the output. If the example fails, it should be easy for the user to fix it.
An example of this is the
make
target in PyAnsys Geometry:The pull request in which this was added is: ansys/pyansys-geometry#1893
This implementation is specific for NB Sphinx, but the idea is to create a target that runs a specific example and checks the output.
The text was updated successfully, but these errors were encountered: