How can I contribute?

Thanks for asking. Let's find a place for you!

Send up an email at contact.pluginthefuture@orange.com.

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

General:

• - 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 ‘README.md’ at the root of your git repo
  • o Documentation is done in separate ‘.md’ files (https://docs.gitlab.com/ee/user/markdown.html) 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