Elexis started as a community effort, and we welcome all contributors. Here’s your chance to get involved and help your fellow developers.
In June 2009 early users (medicial doctors) founded the Medelexis AG, to get professional support for their business critical application. Since then most of the development is sponsored/paid/organized by Medelexis, which runs also an internal bug tracking system (aka as Redmine).
If you wish to contribute code, please get acquainted with our SW
guidelines, which you find in the file
If you find any omission, typos, error or inaccurate statements in any of these documents please report them to the Elexis developpers mailing list.
The release manager also maintains a ChangeLog for each repository and
branch.But as always the
git log command is the ultimate answer.
Bugs (aka Issues)
Medelexis AG runs an internal bug-tracking system redmine for Elexis bugs and improvements, where several hunderds bugs per year (since 2011) are tracked, classified and resolved.
Users and developpers using the free Elexis, may post their problems github issue tracker or directly in the core/base repository, where the problem is rooted.
We really do try to keep bugs to a minimum, and anticipate everything you’ll ever want to do with Elexis. We’re also, not perfect. So you may have found a bug, or have an enhancement in mind, or better yet, a patch to contribute. Here’s what you can do.
Whether it’s a bug, enhancement or patch, send an email using email
Yes, please. The following steps are usually required
- clone the concerned repository(ies), e.g. core or base
- create a feature branch, giving it a meaningful name (e.g. bug_430, add_cool_feature)
- fix the problem
- if possible a unit test for it (you might look at HL7-Tests)
- create a pull request via the github interface “New pull request”
- if you don’t get an answer in a week, insist on the elexis-developer list
- listen to the comments and improve your patch till it can be incorporated
The Perfect Patch
If you want to get your patch accepted quickly:
- Provide a good summary of the bug/fix. We use that to decide which issue we can do quickly, and also copy and paste it into the changelog.
- Provide short explanation of what failed, under what conditions, why, and what else could be affected by the change (when relevant). The helps us understand the problem and move on to the next step.
- Provide a patch with relevant tests. First thing we have to do is replicate the problem, before applying the change, and then make sure the change fixes that problem. And we need to have those specs in there, they make sure we don’t accidentally break it again in the future.
- Provide a patch with the fix/change itself. Keep it separate from the specs, so it’s easy to apply them individually.
If you don’t know how to fix it, but can at least write a test for the correct behavior (which, obviously would fail), do just that. A spec is preferred to a fix.
Working on a new feature?
If you want to work on a cool new feature, but not quite ready to submit
a patch, there’s still a way you can get the Elexis community involved.
We’re experimenting with using Git for that. You can use Git to maintain
a fork of Elexis that can keep up with changes in the main branch (tip:
git rebase), while developing your own changes/features on it.
You are free to license your new feature/plugin under any license you want, but
Living on the edge
Did we mention Elexis is an open source project? In fact, when you install Elexis you get all the source code, documentation, test case and everything you need to use it, extend it and patch it.
Compiling Elexis from scratch can be a time consuming effort if you don’t follow the advise given here. If the procedures mentioned here don’t work for your setup please ask a question at Elexis developpers mailing list before spending hours tracking down bugs.
Start with the Oomp based installer, as described under ch.elexis.sdk
The central repositories are:
Elexis uses the Jenkins continuous integration tool to perform builds, run tests and report back on problems when changes are made to the source code repository.
The care and feeding of the CI Jobs is the responsibility of the committers.
Tested and Documented
Two things we definitely encourage!
Obviously we won’t turn down patches, but we’ll love you even more if you include a test case. One that will fail without the patch, and run successfully with it. If not for our love, then think of the benefit to you: once we add that test case, we won’t accidentally break that feature in the next release.
Yes, we do make typos, spelling errors and sometimes we write things that don’t make sense, so if you find a documentation bug, or want to help make the documentation even better, here’s the way to do it.
For simple typos and quick fixes, just send a message to the mailing list or log an issue in JIRA.
If you end up rewriting a significant piece of text, or add new
documentation (you rock!), send a patch. Making documentation patches is
fairly easy. All the documentation is generated from text files in the
doc/pages directory, so all you need to do is check it out from
Git/SVN, edit, and
svn diff to create a patch.
We use Textile as the markup language, it takes all of a few minutes to learn, it’s intuitive to use, and produces clean HTML. You can learn it all in a few minutes from the Textile Reference Manual. Also check out the Textile Quick Reference.
Syntax highlighting handled by Rouge. Use the
highlight tag to separate code sample from the rest of the
text and to tell Rouge which language to use. For example:
Have a look at existing documentation to see writing conventions. We use the Markdown syntax
This documentation uses Jekyll.