Want to contribute? Great! There are many ways to give back to the project, whether it be writing new code, fixing bugs, or just reporting errors. All forms of contribution are encouraged!
Notice something amiss? Have an idea for a new feature? Feel free to to write an Issue on the GitHub repository about anything that you feel could be fixed or improved. Examples include:
- Unclear documentation
- Bugs, crashes
- Enhancement ideas
- ... and more
Please try to be as descriptive as possible. Provide as much information as you are able to (e.g. browser version, operating system, project version). If you are seeing an error, paste as much of the log as you can.
Of course, after submitting an Issue you are free to tackle the problem yourself (see "Submitting changes" below), and encouraged to do so.
If you want to contribute code but don't know what to work on, we try to always keep some Issues marked help-wanted or good-first-issue. We want everyone to be able to contribute!
We follow the common development process in the company. We use git as our version control system (VCS). We develop new features in separate git branches, raise Pull Requests, put them under peer review, and we merge them only after they pass the QA checks and continuous integration (CI). We never commit directly to the master branch.
For useful resources, please see:
- Git basics for Git beginners
- Git best practices
If you are a complete newbie, click here for an easy-to-follow guide (with pictures!)
We follow the standard procedure for submitting Pull Requests. Please refer to the official GitHub documentation if you are unfamiliar with the procedure. If you still need help, we are more than happy to guide you along!
Note: Before submitting code, please either choose an existing Issue, or write your own, describing the problem you are solving. We would like for every PR to have an accompanying Issue, so that we know concretely what the problem is and can track its resolution.
We try to follow standard best practices for every language and framework we use. These best practices are enforced by CI (see below) and code review (also see below).
We don't have any hard-and-fast rules for styling git commits or branch names, but try to look at existing PRs first to get a sense of how they are structured.
Branches:
user/issuesevey/fix-readme-typo
Commits:
module: descriptionapi: updated documentation for download endpoint
Submitted PRs are expected to pass continuous integration (CI), which, among other things, runs a test suite on your PR to make sure that your code doesn't have any bugs.
Please refer to the README of this repo for instructions on running the CI and test suites locally.
We require that every piece of code is covered, meaning tested. If you aren't familiar with writing tests for the language, make your PR anyway and we'll help you from there.
Your PR will be assigned to a team member and reviewed promptly. More often than not, a code submission will be met with review comments and changes requested. Keep in mind that it's nothing personal -- we leave each other review comments all the time.
After addressing review comments, it is up to your discretion whether you make a new commit, or amend the previous one and do a force-push to the PR branch. It is common practice to amend the last commit, and do a force-push, if there are only minor changes to be made. GitHub now shows diffs for force-pushed commits, making them easy to review.
Your changes will go live with the next version/release, whenever that happens, and the change will be mentioned in the changelog.