Contributing

How to contribute

Step 1: Fork

Fork the project on GitHub and clone your fork locally.

$ git clone https://github.com/{{username}}/performance-benchmark-stack.git
$ cd performance-benchmark-stack
$ git remote add upstream https://github.com/bancolombia/performance-benchmark-stack.git
$ git fetch upstream

If you haven't done it yet, Configure git so that it knows who you are:

$ git config user.name "My name"
$ git config user.email "my personal or business email"

You can use any name/email address you prefer here. We only use the metadata generated by git using this configuration for properly attributing your changes to you in the AUTHORS file and the changelog.

If you would like for the GitHub UI to link the commit to your account and award you the Contributor label after the changes have been merged, make sure this local email is also added to your GitHub email list.

Step 2: Branch

As a best practice to keep your development environment as organized as possible, create local branches to work within. These should also be created directly off of the master branch.

$ git checkout -b my-branch -t upstream/master

We suggest that the name of the branch be separated with hyphens and be concise with what you want to solve, it does not have to start with the word feature or fix.

Which branch:

• Make your pull request target master.

Pull request criteria

• If you are attending an issue, add this id in your pull request.
• Include tests
• For new features consider adding new documentation item in Readme file
• Also, look at the GitHub's Pull Request guide

General info

• Comment on issues or pull requests.
• Please suggest changes to documentation when you find something unclear.
• You can create a fork of Scaffolding project in no time. Go to the github project and "Create your own fork". Create a new branch, commit, ..., when you're ready let us know about your pull request so we can discuss it and merge the PR!

More on pull requests

The Scaffolding project has now a continuous release bot, that means that each merged pull request will be automatically released in a newer version of the plugin. For that reason each pull request has to go through a thorough review and/or discussion.

Things we pay attention in a PR :

• On pull requests, please document the change, what it brings, what is the benefit.
• Clean commit history in the topic branch in your fork of the repository, even during review. That means that commits are rebased and squashed if necessary, so that each commit clearly changes one things and there are no extraneous fix-ups.
• In the code, always test your feature / change, in unit tests.

Commits

Good commit messages serve at least three important purposes:

• To speed up the reviewing process
• To help us write a good release note To help the future maintainers (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added.

Rules:

1. Write the summary line and description of what you have done in the imperative mood, that is as if you were commanding someone. Start the line with "Fix", "Add", "Change" instead of "Fixed", "Added", "Changed"
2. Contain a short description of the change (preferably 50 characters or less, and no more than 72 characters)
3. be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code, like function/variable names
4. Keep the second line blank.
5. If your commit introduces a breaking change (semver-major), it should contain an explanation about the reason of the breaking change, which situation would trigger the breaking change and what is the exact change.
6. Use the body to explain what and why vs. how

For example:

test: add functional test for non-standard base libraries
ci: support for Ubuntu 18 & CentOS 7
deps: upgrade express to 4.17.1
deps: standardjs as style guide, linter, and formatter