Thank you for considering to improve SimPhoNy. We welcome your input!
How to contribute?
|
Issues Report bugs, propose enhancements or suggest new features |
Code Help develop SimPhoNy |
|
Help others understand how SimPhoNy works |
Forum Participate in discussions and answer other user's questions |
Remember that you must adhere to the Contributor Covenant Code of Conduct if you decide to make a contribution.
When you find something that is not working as it should, you can submit a bug report. This section provides guidelines on how to write your report in a way that helps maintainers understand the problem and reproduce it. Submitting a good bug report is a key to have issues solved quickly.
- Consider what is the possible cause of your issue. Sometimes the source of a problem is in the least expected place. For example, it could be in the ontology that you are using, in the network connection or in the software that a SimPhoNy wrapper is interacting with.
- Check the Q&A section of the discussions page. Someone else might have already experienced the same issue and got an answer on how to solve it.
- Search for similar issues on the issue board. The problem may already have been reported. If you are having issues while using a specific SimPhoNy wrapper, beware that each SimPhoNy Wrapper has its own issue board.
Bug reports should be submitted on the SimPhoNy issue board. If you suspect that the issue has its origin in the code of a specific wrapper, rather than in SimPhoNy itself, visit the issue board of the wrapper instead. To create a new report, click the green "New" button.
- Choose a meaningful title.
- Describe the problem in few words.
- Specify which version of
simphony-ospis affected. Usepip show simphony-ospto find out which version you have installed. If the problem involves a wrapper, provide also the version of the wrapper. - Explain how to reproduce the problem, step-by-step, and include a minimal reproducible example. A minimal reproducible example is a code snippet where the issue can be observed. Include any additional files (e.g. an ontology file) that may be needed to execute the example. Skip the example only if it is very difficult to provide it.
- If the issue involves a crash or an exception, include the full error message (with the stacktrace).
Follow this link to see an example of an accurate bug report. Providing a good bug report facilitates the work of the maintainers and enables them to solve the issue faster.
Enhancements or new features should first be proposed on the "Ideas" section of the forum.
When proposing, discussing, and designing a feature or enhancement on the forum, always aim to address the following points:
- Motivation for the enhancement or the new feature.
- General overview of the enhancement or the new feature. Code snippets/mock-ups of how the feature or enhancement should work and behave.
- Estimation of the effort that implementing such enhancement or feature might involve. Technologies that could enable the implementation. This information helps the maintainers decide whether to implement a feature or enhancement, and to estimate the timeframe for a potential implementation.
After this discussion phase, when the maintainers deem it appropriate, the discussion on the forum can be closed and an issue referencing it can be created on the issue board. The goal of this procedure is to separate discussion and design from implementation efforts. The issue is now ready to be worked on. The code section explains how to contribute to solve an issue.
Code contributions are generally aimed at fixing bugs and implementing enhancements or new features. The way to contribute code to the project are pull requests (PR).
If you are unsure about where to start, check the issues tagged as newcomer task. Such issues should either be simple to solve, or be a good entry point for understanding the codebase.
If you have a bugfix or a feature/enhancement implementation that you want to contribute, please read this page to understand how the code is organized, what the meaning of the different git branches on the repository is, and what automatic checks your code will have to pass in order to be accepted. After that, just fork the repository and make a new pull request.
Usually, there will be an issue associated with the specific bug to solve, or feature/enhancement to implement. Please add closing keywords to your PR so that it becomes automatically linked to the corresponding issue.
After you submit your pull request, a maintainer will review it. It is possible that additional work is needed before the maintainer can accept the PR. To make things smoother, please consider allowing us to directly edit your PR, so that we can perform minor edits without having to wait for your feedback.
Of course, even if you are not a maintainer, you are also very welcome to comment on the pull requests submitted by other community members and give feedback to them.
If you feel that the SimPhoNy documentation is difficult to understand, we welcome your feedback and contributions! In general, changes to the documentation should be first proposed on the "Ideas" section of the forum.
However, in certain cases, a change in the documentation does not need to be discussed. For example, if you find a typo you can directly create an issue or even a pull request. The same applies if the documentation needs to be changed due to the implementation of enhancements or new features for SimPhoNy in a code contribution.
When proposing and discussing a change on the documentation, always aim to always aim to address the following points:
- Motivation for the change or addition.
- A brief description, of the proposed changes.
- A mock-up of the intended changes, for example the headings, a few sentences explaining the content that should be included. If the changes involve figures, please upload a sketch too.
After this discussion phase, when the maintainers deem it appropriate, the discussion on the forum can be closed and an issue referencing it can be created on the issue board. The goal of this procedure is to separate discussion and design from implementation efforts.
The issue is now ready to be worked on. On the issue itself, the fine details and the actual contents can be more deeply discussed. Finally, a pull request can be submitted to the docs repository. A maintainer will review the pull request and accept it, or request further changes if needed.
Feel free to participate on the forum! There you may:
- Read announcements from the SimPhoNy team.
- Have general discussions about SimPhoNy.
- Propose new features or enhancements. Please follow the guidelines provided on this section.
- Ask other members of the community for help in a Q&A format.
- Share how did you benefit from using SimPhoNy in your project.