We would be delighted if you contribute to Lexonomy and make it even better than it is today!
- Question or Problem?
- Issues and Bugs
- Feature Requests
- Submission Guidelines
- Coding Rules
- Commit Message Guidelines
- Signing the CLA
- Code of Conduct
Do not open issues for support questions, as we want to keep GitHub issues for bug reports and feature requests. You have a much better chance of getting an answer to your question on the elexis-lexonomy Google Group.
If you find a bug, you can help us by submitting an issue to our GitHub Repository.
You can request a new feature by submitting an issue to our GitHub Repository. If you would like to implement a new feature, please submit an issue with a proposal for your work first.
Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.
Before fixing a bug we need to understand and confirm it. In order to understand bugs, we will ask you to provide all necessary information.
You can file new issues by selecting from our new issue templates and filling out the issue template.
To ensure consistency throughout the source code, keep these rules in mind as you are working:
- We follow the following style guides
- JavaScript standardjs.com Style for JavaScript
- PEP 8 - Style Guide for Python Code for Python
- Features or bug fixes should be tested by one or more specs.
- All public API methods must be documented.
We have a few ideas about how git commit messages should be formatted. We think, this leads to more readable messages that are easy to follow when looking through the project history. We also use some git commit messages to generate the change log.
Each commit message consists of a subject, a body and a footer.
<subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Any line of the commit message should not be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
The subject contains a succinct description of the change:
- do capitalize the first letter
- use the imperative, present tense: "change" not "changed" nor "changes"
- no dot (.) at the end
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain a closing reference to an issue if any.
Please sign our Contributor License Agreement (CLA) before sending pull requests. The CLA must have been signed for code changes to be accepted. It won't take long, we promise!
Help us keep Lexonomy open and inclusive. Please read and follow our Code of Conduct.