BoltCM

Sophisticated, Lightweight and Simple

Jump to docs navigation
Edit on GitHub

Note: You are currently reading the documentation for Bolt 3.0. Looking for the documentation for Bolt 3.2 instead?

Other » Contributing to Bolt

Whether you're a user of Bolt, a developer or both: contributing to Bolt is easy! This document shows what you can contribute and how to contribute to make it an even better product!

How you can contribute

Contributing docs or code

Basically this comes down to forking, branching and issuing pull requests. For some background information your can read this help/manual of Github.

Fixing particular issues

When you're going to work on a particular issue, be sure to make a separate branch for it as this allows for better separation between the issues you're working on. This also helps us analyzing pull requests and we simply cannot accept pull requests with a lot of fixes running across each other. We try to work in the following way (which is pretty common on Github projects):

Creating a new feature

For a new feature there is a three step process:

Note: This obviously doesn't include bug fixes

Step 1 - RFC submission

Create a GitHub issue with the prefix of [RFC] in the subject line.

Describe:

Step 2 - RFC moved to Roadmap

Once approved, a core team member will add the feature and contributor's GitHub handle to the Roadmap wiki page

Step 3 - Feature implemented and merged into version -next

Once the feature window is open the contributor can submit a PR for review and merging.

Step by step guide to forking, branching and pushing

If you're not yet proficient with forking, branching and pushing your fix, here's a step- by-step guide: This example assumes that you have a Github account and uses the bolt code repository. The commands also hold for the other repositories. The only thing which should be changed is the repository url. The steps cover this help/manual of Github. Lines starting with # are comments, lines with $ are commands which you need to execute in your terminal.

Pull Request Details (PR)

Details of your changes should be susinctly documented in the pull request. For new features it should include a short use case and justification.

Along with notating any issues the PR fixes, it should include mentions of any other PRs it depends on, and any relevant changelog updates.

As an example:

These changes stop kittens from crying due to poorly formatted CatNip requests.

Fixes #1024
Fixes #2048
Depends on #3072

Changelog
---------

* Feature: My change does something cool (see #1024)
* Fixed: Something that was broken (see #2048)
* Updated: FooBar library to v1.3.6

Couldn't find what you were looking for? We are happy to help you in the forum, on Slack or on IRC.
Spotted a typo, or have something to add? Edit this page on GitHub.