Get in touch !

You can get in touch with us for support by sending an email to

If you wish to contribute or if you have any other inquiries regarding your data, please send an email to

Contribute to Plug'in

How can I contribute?
Thanks for asking. Let's find a place for you!

Send up an email at

Atom development

Read the Plug'in documentation, which is intended for researchers, developers, operationals, etc. who are standing up experiments on top of Plug'in. The documentation can be edited by cloning a git repository.

If you find problems with content on the Plug'in documentation, log an issue against the correspondent atom project with the page that contains the bug. Hint: you can just dump useful text into a bug report, and the documentation team will format it and update the docs for you.

Check out how we work:

  • - Read the documentation to get started: here
  • - How to raise issues: coming_soon.php /<project name>/issues
  • - Get the code


  • - Use revision control (git) for the code base
    • o Prefer small commits to better track changes
    • o Use tags for usable versions
    • o Use branches when necessary (merge afterwards)
  • - Declare dependencies (explicitly)
    • o If your codebase is in Python, use a flat requirements.txt with module version, if nodejs use package.json (or similar)
  • - For infrastructure, it should be reproducible with a file:
    • o Vagrantfile, Dockerfile, Makefile
    • o Declare all the necessary packages: .debs, .rpms, .tars, gits… in the provisioning phase of your infrastructure
  • - Configuration should be *at least* available through: defaults, file, environment. One should add the possibility of datastores such as etcd or consul
  • - The use of backends (databases, authentication services (keystone), remote logging) should be configurable
    • o Specify the URL or IP in one of the configuration files, with possibility of change through environment variables
    • o Handle the case where these services are unavailable through meaningful error messages and coherent trials/grace periods (for examples, ping the service 5 times with an exponential delay, and exit with an appropriate error message and code to signal that the service is unavailable)
  • - Write tests for your code
    • o No code coverage is specified but important portions should be tested. Important is at the developer’s discretion
    • o These tests should be the basis of CICD integration/regression tests
  • - Open port numbers should be configurable
    • o If not possible through the app itself, the option should be given through the delivered infrastructure code (Vagrantfile, Makefile, Dockerfile)
  • - Logging should be handled with the importance it requires
    • o Take into account the possibility of external logging services (ELK, other logging as a service); i.e. one possible production-grade configuration is to provide the infrastructure with a log shipper such as filebeat or logstash
  • - Document your APIs in the appropriate formats
    • o OpenAPI (former Swagger) for Rest HTTP APIs (.json, .yaml, or interactive with swagger-ui)
    • o Readthedocs/apidoc/doxygen/godoc… for other API documentation (at the discretion of the developer)

Plug'in specific:

  • - Locate the documentation under ‘/docs’ and ‘’ at the root of your git repo
    • o Documentation is done in separate ‘.md’ files ( that we later export to static html files
  • - A ‘metadata.json’ file should also be located in the root of the git repo
    • o no specification yet for this file yet (work in progress). Only include ‘{}’ in the file for the moment
  • - Recommendations for the rest of the automated (Atom -- Atomdocs, Atomstore) conversion process in ongoing
The above recommendations ensure future compatibility with our platform and better reusability of computer science and engineering based research