Skip to content

Latest commit

 

History

History
94 lines (61 loc) · 4.08 KB

CONTRIBUTING.md

File metadata and controls

94 lines (61 loc) · 4.08 KB
Raw

Contributing

Contents

Reporting bugs

Before submitting your issue please check that you've completed the following steps:

  • Made sure you're on the latest version
  • Used the search feature to ensure that the bug hasn't been reported before

Bug reports should contain the following information:

  • Summary: A brief description.
  • Steps to reproduce: How did you encounter the bug? Instructions to reproduce it.
  • Expected behavior: How did you expect it to behave?
  • Actual behavior: How did it actually behave?
  • References: Links to any related tickets or information sources.
  • If possible, attach visual documentation of the bug. Screenshot or animated gif

Development Process

At EOS Costa Rica we use Github's Projects board to prioritize the work and the standard Github Flow https://guides.github.com/introduction/flow/ for code changes.

We follow the open source collaborative ettiquete and the standardjs code style.

We use a Kanban-style board with built-in triggers to automatically move issues and pull requests across To do, In progress and Done columns. That's were we prioritize the work. Go to Project Board.

Pull Request General Guidelines

  • Please check to make sure that there aren't existing pull requests attempting to address the issue mentioned.
  • Check for related issues on the issue tracker.
  • Non-trivial changes should be discussed on an issue first.
  • Let us know you're working on the issue.
  • Develop in a topic branch, not master.
  • Provide useful pull request description
  • Write a good description of your PR.
  • Make well scoped pull requests. 1 PR per feature of bug fix.
  • Reference the github issue on the pull request description.

Commit Standards

  • Make atomic commits, don't mix unrelated code changes.
  • Provide useful commit messages.
  • Provide a short commit message in the first line (50-100 character). Looking at the output of gitk or git log --oneline might help you understand why.

Working on Your First Pull Request?

You can learn how from this free series How to Contribute to an Open Source Project on GitHub

Advanced Git tools

There are also tools like Hub and git-extras that facilitate interacting with Github. You can leverage these tools to contribute to this repository.

Version Numbers

Semver, except the version roles have the semantic names, "Breaking.Feature.Fix" instead of "Major.Minor.Patch".

Breaking.Feature.Fix

We don't decide what the version will be. The API changes decide. Version numbers are for computers, not people. Release names are for people.

Breaking

Any breaking change, no matter how small increments the Breaking version number. Incrementing the Breaking version number has absolutely no relationship with issuing a release.

Feature

When any new feature is added. This could be as small as a new public property, or as large as a new module contract being exposed.

Fix

When a documented feature does not behave as documented, or when a security issue is discovered and fixed without altering documented behavior.