Skip to content

Latest commit

 

History

History
91 lines (63 loc) · 5.69 KB

CONTRIBUTING.md

File metadata and controls

91 lines (63 loc) · 5.69 KB
Raw

Contribution guide to SeaClouds

Great to have you here. If you want to help us with the development of this project please read this document carefully first. Here are a few ways you can help make this project better!

Learn & listen

If you want to learn more about the project status, or asking some question about our work feel free to gather more information about us here:

Also we encourage to learn more about the project by reading the project deliverables related with the core module you want to study in order to understand better the decision made to achieve the project objetives.

Project structure

The project is divided in the following components referred in the documentation of the project:

  • dashboard: user interface as a web application that integrates all other SeaClouds components. More information.
  • deployer: The deployer is in charge of following the instructions coming as a deployment plan coming from the Planner. More information
  • discoverer: This sub-system is in charge of identifying the available capabilities offered by cloud providers that will be used by the Planner sub-system to perform a matchmaking process. More information.
  • monitor: More information.
  • planner: in charge of determining a distribution of application components onto multiple available clouds so that the QoS properties and other technology requirements needed for individual application components are not violated. More information.
  • api: TODO.
  • sla: is in charge of mapping the low level information gathered from the Monitor into business level information about the fulfillment of the SLA defined for a SeaClouds application. More information.

How to contribute

Create an Issue in Github

The first step is usually to create or find an issue in SeaClouds' Github for your feature request or fix. For small changes this isn’t necessary, but it’s good to see if your change fixes an existing issue anyway.

Some good references for working with GitHub are below. We ask that you keep your change rebased to master as much as possible, and we will ask you to rebase again if master has moved before accepting your patch.

For more information, please look at github FAQ

Before creating the PR

Some best practices to submit a good PR:

  • create a feature branch (feature/SEACLOUDS-2345) or a fix branch (fix/SEACLOUDS-123) on your forked repository
  • code your patch
  • rebase your branch
  • test your code locally!
  • commit your code and push it to a remote
  • create the PR from Github website

Your commit messages must properly describes the changes that have been made and their purpose (here are some guidelines). If your contributions fix a Github issue, then ensure that you follow our rules about the commit message.

Each commit must have the following structure (since 17/12/2014): <type>(<scope>): <subject> ( e.g. “FIX (dashboard): Modified resizing on app-monitoring section” )

Type

  • FEATURE : A new feature.
  • FIX: A bug fix.
  • DOCS: Documentation only changes.
  • STYLE: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
  • TEST: Adding missing tests.

Scope

Scope of the changes, often it will be the name of the module involved in this commit (planner, monitor, deployer…).

Some Words of Advice

  • Include documentation and tests.
  • Keep your code clean and readable (avoid pushing commented code!)
  • Try to imitate the existing code style. New code added to Git is expected to match the overall style of existing code.

Don’t get discouraged! We estimate that the response time from the maintainers is between 5 nanoseconds and when-we-can-answer-you.

Bug triage

If you find a bug while using or contributing to SeaClouds feel free to create a new issue on GitHub and label it as “bug”. Some advices when reporting:

  • Make sure your bug is not already reported before posting it.
  • Provide all the error logs and information that can help us understand what’s going on (using a snippet tool like Gist or Pastebin is recommended when handling large logs).
  • Is the bug reproducible? List the steps and platforms used necessary to make it visible (which browser are you using, which Java version, …)

Documentation

Please have a look at the Readme.md file inside each project module. It contains the necessary information to understand the basic functionality and how it works in conjunction with the other parts of the projects.

We will provide the public deliverables related with each of the project components in the main project website.