LumiSpy is meant to be a community maintained project. We welcome contributions in the form of bug reports, documentation, code, feature requests, and more. In the following we refer to some resources to help you make useful contributions.
The issue tracker can be used to report bugs or propose new features. When reporting a bug, the following is useful:
give a minimal example demonstrating the bug,
copy and paste the error traceback.
If you want to contribute to the LumiSpy source code, you can send us a pull request. Small bug fixes are corrections to the user guide are typically a good starting point. But don’t hesitate also for significant code contributions - if needed, we’ll help you to get the code ready to common standards.
Please refer to the HyperSpy developer guide in order to get started and for detailed contributing guidelines.
The kikuchypy contributors guide, another HyperSpy extension, also is a valuable resource that can get you started and provides useful guidelines.
As quality assurance, to improve the code, and to ensure a generalized functionality, pull requests need to be thoroughly reviewed by at least one other member of the development team before being merged.
The LumiSpy documentation consists of three elements:
A set of curated Jupyter notebooks in the LumiSpy demos repository on GitHub that provide tutorials and example workflows.
Improving documentation is always welcome and a good way of starting out to learn the GitHub functionality. You can contribute through pull requests to the respective repositories.
Package imports should be structured into three blocks with blank lines between them:
standard libraries (like
third party packages (like
All functionality in LumiSpy is tested via the pytest
framework. The tests reside in the
test directory. Tests are short methods that call
functions in LumiSpy and compare resulting output values with known answers.
Please refer to the HyperSpy development guide for further
information on tests.
Releasing a new version
LumiSpy versioning follows semantic versioning and the version number is therefore a three-part number: MAJOR.MINOR.PATCH. Each number will change depending on the type of changes according to the following:
MAJOR increases when making incompatible API changes,
MINOR increases when adding functionality in a backwards compatible manner, and
PATCH increases when making backwards compatible bug fixes.