If you're reading this section, you're probably interested in contributing to Symupy. Welcome and thanks for your interest in contributing!
A general road plan should be available as a main issue entitled Roadmap Plan
in the issues page. This plan is intended to collect the general plan of activities within the development process. In addition this issue intends to capture the general features that will be present in future releases of the software. In general, the intention of the plan is to keep a list of pending topics to work on. These pending topics could be: new features, bugs, documentation issues. Each one of the topics listed in the general plan should be associated to the corresponding issue
When reporting bugs please provide a complete description on the situation and provide information regarding the version of the system you are using, the operative system, and the steps to reproduce the bug. Please attach supporting files to enhance the bug documentation and provide more robust solutions and alternatives.
We are always happy to listen about new ideas and features to be introduced. Please open a new issue in the corresponding category to propose new features.
The development methodology is based on the git flow. For the sake of clarity
- In general all the stable version is preserved in the
main
branch. - Development features are preserved in the
dev
branch
A procedure in general to introduce changes is as follows:
- Create the
new feature
or thehotfix
via the classic commands - Perform the corresponding changes in the local machine
- Push the corresponding changes online
- Create Pull request integrating changes from the created branch into the
dev
branch. Assign this Pull request to a reviewer just to check that your feature/hotfix is correctly working. - Merge Pull request into the
dev
branch - Create new releases according to the established calendar.
All code is written either in Python or C++.
To contribute to the source code please consider the following guidelines:
-
Important when adding new functionalities please document with examples as fast as they are created.
-
When creating a function use Typing. for providing guidelines about the type of arguments.
-
Put the majority of the documentation in the
docstrings
of the code. -
This documentation follows the guidelines of Google Python Style Guide. Docstrings may extend over multiple lines. Sections are created with a section header and a colon followed by a block of indented text.
def create_object(type:str)-> object: """ This functions will create an object of a certain type Args: type (str): Type of object to be created Returns: object: Created object Example: An example to use is the following:: >>> my_object = create_object("type") """ ... code to create object return object
-
It is recommended as a good practice to use
CamelCase
notation for meta class or class definitions, andsnake_case
notation for variables and functions. A good way to validate this is via a linter. It is recommended to use pylint as a linter. -
Automatic code formatters can be used for this case black.
-
For C++ code it is recommended to use Doxygen for generating auto documentation, more information is available in this blog post