manifest manifestThe Samply community started as a group of software developers and scientists from research institutions at different locations. Its purpose is to build software for scientific purposes, networking and federated research. As an open source community, it is our goal to provide the Samply software developed during individual projects to all members of the community.
Originally established within the German Cancer Consortium (DKTK), the Samply initiative's open-source licensed software is now used by several European scientific projects and research networks.
All members of the Samply community are expected to comply with the principles and conventions of the Samply manifest.
Each individual member of the Samply community moreover adheres to the rules of the Berlin Code of Conduct.
The Samply community is self-organised and committed to dividing the workload of creating software requirements, writing code and reviewing pull requests.
An open communication culture prevails. Although we develop and use Samply in a variety of independent research projects, we are committed to communicating ideas, problems and changes openly.
For discussions, questions, complaints or feature requests, contact the developers via the Samply mailing list or via one of the project issue trackers, e.g. Sample Locator, Bridgehead or Blaze Store.
Our working language for documentation is English. In meetings, we will choose our working language based on the preferences of the attendees.
Each Samply component is curated by one or more maintainers. Those who engage intensely in the development and enhancement of a component are predestined to become its maintainer (see list of component maintainers).
If you would like to join the Samply community, please register for our Samply mailing list by sending an email to join(at)samply.de. You can also leave the community by sending a mail to this list. Communication via the mailing list is archived and may be made public.
Our source code is provided "as is" without warranty on our public GitHub repositories. The maintainer of the repo is reponsible for deciding on appropriate licencing of the source code. We recommend Apache 2.0.
It is assumed that each member of the Samply community contributes to the processing of requirements and pull requests according to their own abilities and interests.
We aim to provide Docker buildfiles for each Samply application, and to publish them on Docker Hub.
We do not have Samply-wide release trains. However, each project employing Samply can maintain 'Samply distributions' to establish their own release trains.
Component maintainers are the contact persons for the components and allowed to approve pull requests and release new versions. They are responsible for implementing bug fixes and keeping the component compatible with linked components.
The members of the Samply community are self-obligated to adhere to our criteria catalogue for pull requests.
Make your code as clean as possible according to coding best practices (check out 'Clean Code' by Robert C. Martin for reference).
Projects will be version-controlled according to Gitflow. There are two permanent branches, 'master' and 'develop'. Temporary branches can be established in addition to this for features, hotfixes and release.
The software versioning uses a three-figure version number, following the guidelines of Semantic Versioning 2.0.0.
The master branch is the current stable release version. The develop branch is a copy of the latest master branch containing additional newly developed features and changes. It forms the basis for the next release.
Never work in the master branch! Establish a new temporary branch from the current develop branch for development (e.g. feature, hotfix), which will be merged into the develop branch following a successful pull request.
It is possible to add the appendix 'SNAPSHOT' for versions under development. Avoid dependencies from a SNAPSHOT version, unless the concerned version is also a SNAPSHOT. The develop and master branch must never depend on SNAPSHOT versions.
Pull requests should be addressed by the responsible component maintainers. To approve a pull request, the acceptance of a component maintainer is required.
Component maintainers need to be aware that pull requests are of high priority and should be tended to within 2 days. Delays in pull request approval might otherwise slow down the entire developement process.
Only the component maintainers are allowed to merge branches into develop and to push from develop into the master branch for a new release. New features should be merged from the develop into the master branch within two weeks.
For Java software, we support one OpenJDK version on release.
We endeavour to keep external dependencies as low as possible. External libraries have to be agreed by the affected component maintainers before use.
Each modification should be communicated to the component maintainer. Other involved community members should also be informed promptly.
Whenever a modification is made to interfaces, we will perform a system test.
We use a Samply license header for our software. Embedding this header is a requirement for each Samply component.
For each release, we ensure compatibility is maintained between connected Samply components (for combinations, check the releases tabs or the docker compose files of the deployments at GitHub/Samply). If necessary, we modify affected Samply components to ensure compatibility.
Only when there are very good reasons do we deviate from the rules of this criteria catalogue. Please inform affected community members about any deviations promptly.