Skip to content

Latest commit

 

History

History
84 lines (67 loc) · 5.12 KB

CONTRIBUTING.md

File metadata and controls

84 lines (67 loc) · 5.12 KB
Raw

Information for contributors

Great to see you. We appreciate your interest in contributing to ELIXIR Cloud Components. The project is open for community contributions, please read the following guidelines carefully before making any contributions.

If you don't know what ELIXIR Cloud Component is all about, just follow the link. Otherwise read on to find out more about our values and how you can contribute.

General

Our values

  • Openness: all of our code is open source, usually from day one, and available publicly under a license approved the Open Source Initiative
  • FAIRness: we want data, code, analysis workflows and infrastructure to be findable, accessible, interoperable and reusable
  • Privacy: we believe that sensitive personal data should be under the control of the individual and should be shared, processed and analyzed only upon and to the degree covered by informed and specific consent, using the highest security standards

Design guidelines

  • Components MAY be nested, i.e., a component may import other components to create one or multiple levels of child components
  • Components SHOULD provide basic, clearly defined functionalities; for complex functionalities, nest multiple components in such a way that the top-level as well as all child components each provide basic functionality

Code repository

  • ELIXIR Cloud Components are reusable frontend components that follow the Web Components design/feature set
  • Components should be implemented based on the Stencil toolchain and published under the Apache 2.0 license
  • Components should be made public from day one and live inside their own project directory in the monorepo located at https://github.com/elixir-cloud-aai/web-components
  • Developers should use semantic commit messages following the Conventional Commits specification to allow for automated versioning and changelog creation.
  • Code changes should be proposed through feature branches and be reviewed by at least one reviewer before being merged into the main or dev branches.
  • Fast-forward merges/rebases should be used, and all commits should be squashed or grouped together under individual semantic commits
  • If commits are not to be squashed when merging, they SHOULD be interactively rebased to include few semantic commits (i.e., different topical changes to the codebase or different new features or bug fixes should be grouped together under individual commits)
  • Code changes must pass all CI tests and maintain 100% test coverage

Our expectations

We would only expect you to

  • please respect our Code of Conduct
  • make an effort to adhere to good coding practices and our contribution guidelines (we will of course help you with that!)
  • communicate clearly and openly with us with regard to any issues that you take responsibility for, especially if you realize that you cannot or do not want you to continue with something (which is of course totally fine!)

Contribute via GitHub

  1. Explore issues section on github and see if there is anything that you would like to work on in particular (links to issue boards are available and most projects should have one or more issues flagged as good 1st issue); or perhaps you would like to propose an issue or even a project yourself?
  2. Sign up to GitHub
  3. Before you start working on your first issue, please carefully read the contribution guidelines
  4. Assign yourself to the issue of your choice
  5. Start coding :)