First off, thank you for taking the time to contribute 🙌🏼 Any contribution is welcome and appreciated. Below you'll find an overview of contribution guidelines, with what's expected of contributors.
Before you get started, please make sure you read and understand our Code of Conduct.
Table of contents
- Setting up and getting started
- Reporting a bug
- Suggesting a new feature
- Contributing to an existing issue
- Issue labels
The Travis Foundation website is built using Jekyll. In order to set up and run the site locally for development, you'll need to have Ruby and RubyGems installed on your machine, have a GitHub account, and fork our repo.
Once you're all set up, you'll have to bundle the gems using Bundler and start Jekyll. Type the following into your terminal / shell session:
gem install bundler
bundle install
bundle exec jekyll serve --watch
To see the site locally, just head to http://localhost:4000 in your browser. If you are new to Jekyll, you can find more about it here. Otherwise, you're ready to go!
Before reporting a bug, please check if it has already been reported. If it hasn't and you want to file a new bug report, provide the following information:
- Where/on which page did the error happen?
- How can the error be reproduced?
- What was the expected and what the actual behaviour?
- Can you provide an error message or a screenshot that illustrates the problem?
We are open to suggestions and ideas to improve the website. As with filing a bug report, before suggesting a new feature or giving feedback please check it has not been suggested before. And if it hasn't, feel free to share your ideas on our issue tracker!
You can view all of the currently open issues on our issue tracker. Most are labeled, to give you an idea of the sort of contribution that is expected.
A good starting point if you're new to open source is the list of beginner-friendly issues. These are issues that don't require much prior knowledge of our structure or our website to get started. Before getting started, please check that no one else is working on the issue: this will be clear by the assigned user (if there is one) and by the issue's comments/discussion.
If it seems like no one is working on the issue, great! You've officially found an issue to work on. You can leave a comment mentioning you'd like to work on the issue. Feel free to also leave a comment with your questions, if anything is unclear or if you need help: Is the issue still valid? Are there any more detailed specifications to the issue?
Once you're happy with your changes, commit them and make a pull request. You can find very thorough information on Pull Requests in GitHub's documentation.
❗️ The most important thing to keep in mind is that all pull requests should be made against master, which is our main branch.
We use labels to track, manage and organise issues and pull requests.
| Label Name | Issues | Description |
|---|---|---|
beginner-friendly |
🔍 | Less complex issues, suitable for your first steps in open source. |
bug |
🔍 | Confirmed misbehavior of the application code. |
design/styling |
🔍 | CSS, UI and design-related issues. |
documentation |
🔍 | improvements to current documentation (e.g. README, contribution files) |
duplicate |
🔍 | Issues which have already been reported. |
enhancement |
🔍 | "nice to have" features, but not necessary. |
in progress |
🔍 | Work in progress, things which are already taken care of. |
pair with me |
🔍 | Looking for someone to pair on this. |
question |
🔍 | Feature and code related questions which are no bug reports or feature requests. |
quick win |
🔍 | Issues and pull requests which have been reviewed and are ready to be closed or merged. |
ready |
🔍 | Issues and pull requests which have been reviewed and are ready to be closed or merged. |
wontfix |
🔍 | The team has decided to not fix these things for now, e.g. because the whole feature will be replaced soon. |