Thank you for your interest in making coko even better and more awesome. Your contributions are highly welcome.
There are multiple ways of getting involved:
Below are a few guidelines we would like you to follow. If you need help, please reach out to us: melkani.bhaskar@gmail.com.
Reporting bugs is one of the best ways to contribute. Before creating a bug report, please check that an issue reporting the same problem does not already exist. If there is an such an issue, you may add your information as a comment.
To report a new bug you should open an issue that summarizes the bug and set the label to "bug".
If you want to provide a fix along with your bug report: That is great! In this case please send us a pull request as described in section Contribute Code.
To request a new feature you should open an issue and summarize the desired functionality and its use case. Set the issue label to "feature".
This is a rough outline of what the workflow for code contributions looks like:
- Check the list of open issues. Either assign an existing issue to yourself, or create a new one that you would like work on and discuss your ideas and use cases.
- Fork the repository on GitHub
- Make commits of logical units.
- Write good commit messages (see below).
- Submit a pull request to bhaskarmelkani/coko
Thanks for your contributions!
The workflow that we use to contribute is mostly based on GitHub Flow
master is the latest stable version and should be used when opening feature branches.
If a github issue is related to a branch we suggest to append the number at the start of the branch name.
example: 9-add-caching (github issue)
If a feature branch is outdated always rebase it against master instead of merging it.
Always open a pull request to merge into master branch.
Consider opening a PR as soon as a commit on the feature branch is available to ease the reviewing process,
you can add a WIP: prefix to communicate that the current PR is still a work in progress.
We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. It is important to note that we use the git commit messages to generate the Changelog document.
A detailed explanation of guidelines and conventions can be found in this document.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>Any line of the commit message cannot be longer 100 characters!
This allows the message to be easier to read on github as well as in various git tools.
Must be one of the following:
- feat: 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)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
The scope could be anything specifying the place of the commit change.
The subject contains succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize first letter
- no dot (.) at the end
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes" The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit eventually Closes.
Breaking Changes are intended to highlight (in the ChangeLog) changes that will require community users to modify their code with this commit.
refactor(button): add caching, closes #34
Add page caching.
BREAKING CHANGE: add caching