Guidelines to Lombiq's open-source projects

Hey there, fellow open-source enthusiast! We are so happy that you're here and are showing interest in our open-source projects! We really appreciate that you want to be part of our community and also want to help contribute to these projects, but just before you jump into work, please take some time and read through our simple guidelines. Don't worry, more specific information is always in the given repository's Readme file. Want to see all the stuff we've done? Check out all of our open-source projects listed on GitHub and see what else we're doing in open-source.

Branches, tags, and releases

The most important branch of the repository will be the default one on GitHub, i.e. the one selected by default when you open its GitHub page. Ongoing development is almost always done in the dev branch. So, if you want to get the latest but still usable source then checkout that one, or if you want to contribute, please branch off from it. For Orchard extensions when it has an Orchard Core and Orchard 1.x version too then commonly the Orchard Core one is in the dev branch and the Orchard 1.x one in the dev-orchard-1 branch.

For most projects we have releases (like for the Hastlayer SDK which you might want to check out to see some magic): We add a tag with the version number to the latest commit of that release and publish it on GitHub as well as on NuGet. If you want to use them in your own projects in source form, just grab the latest dev branch.

Running the projects locally

  • If you want to contribute to our Orchard Core extensions, then please do so from the Open-Source Orchard Core Extensions (OSOCE) solution since that's the simplest way of doing it: Everything will just work, and you'll get static code analysis support and automated tests.
  • Otherwise, you'll find a solution file in each non-OSOCE repository; just open it and you should be good to go with F5 (or Ctrl+F5).

Coding guidelines

Please follow the software development guidelines elaborated in the Orchard Dojo Library. Otherwise, you'll find that apart from a few points, we follow the most widely used best practices and coding styles of the respective language/technology. Also, if you just look at the rest of the code in a given project, you'll mostly see how we write programs so just try to write code in a similar manner if you contribute. In most of our projects, coding guidelines will be automatically enforced by analyzers as well. That's all.

Pull requests and code reviews

Please open a pull request (PR) for your changes.

  • If you're working on an issue, reference it from the PR description as Fixes #issue-id, e.g. Fixes #123.
  • After you receive a review, once you're done addressing all feedback, re-request review from the reviewer (see upper right corner, under "Reviewers").
  • Don't resolve conversations, so the reviewer can keep track of what happened and can resolve themselves.

Support and security issues

Unless otherwise specified the project's support channel is the issue tracker on GitHub, so please open issues there if needed. If you're looking for commercial-grade support, then that's also available. Feel free to get in touch with us and tell us where you're stuck, what problems you're facing, or what questions need to be answered - we're happy to help!

If you have found a security issue with one of our projects, please get in touch with us directly via security at before disclosing it publicly and we'll look into it ASAP. E-mails sent to this address are received by at least two engineers of ours.

Code of conduct

Please follow Wheaton's Law.