Skip to content

Latest commit

 

History

History
61 lines (32 loc) · 2.83 KB

CONTRIBUTING.md

File metadata and controls

61 lines (32 loc) · 2.83 KB

Contributing to Cranbtree

This document covers the contribution guidelines for contributing to this project. These are merely guidelines to make sure the contribution process is smooth and efficient and are not meant to be rules.

Code of Conduct:

It is important that you go through and abide by the contributor-covenant code of conduct.

Docs:

Before contributing, going through the docs is of great importance because the docs explains the structure of the code and the patterns used. It also highlights the algorithms and approaches used in building and operating on the B-Tree.

Hints for reading the docs: The README.md file in the docs folder has a list of all the documents that you might want to go through listed in a suggested order. It is important that you familiarize yourself with the code and the location of different functions, pieces and structs. Moreover, the docs goes through algorithms that operates on the Tree and their implementation. For the algorithms, in some cases you wont have to study the them to contribute.

Reporting bugs:

Before opening an issue:

  • Make sure it is really a bug, not a misuse in using the libraries function.
  • Make sure the bug was not reported before.

Contributing to the docs:

  • It is important to make sure that you are actually adding something to the documentations not just repeating what is being said elsewhere.
  • Be clear, brief and to the point.
  • Clearly define any special terms that you are planning to use.

Contributing to the code:

The source code was built based on Test-driven development. It is important that you domenstrate and convince yourself and others that the piece of code that you added is actually doing what it is supposed to be doing and this brings us to the first rule:

  1. Always test functions and features that you planning to add.
  2. refactor code and avoid duplications.
  3. Use existing functions if possible.
  4. Make sure you do not break something while creating something new.
  5. Always open an issue first before you start working on a new function and make sure no one is working on something similar.

Opening an issue:

  1. Make sure the issue is not opened before.
  2. Be clear about what needs to be changed or fixed.
  3. Feel free to suggest enhancements as long as you are clear in you description.

Sending a pull request:

  1. Do not send a pull request with code that contains any kind of syntax error.
  2. Before sending a pull request always make sure you tested your code and that the other code does not break.

Gitter

before asking questions on Gitter make sure that you have read the documentations thoroughly and follow the code of conduct while dealing with others on gitter

Happy Coding