First of all, thank you for considering contributing to this project ! 🎉
There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests, or writing code that can be incorporated into the project. In order to make a good experience for both contributors and maintainers, please start with the "General Rules" before taking further action.
- General Rules
- Questions and Requests for Help
- Reporting a Bug
- Suggesting a New Feature
- Contributing Code/Documentation
- Helpful Resources
All types of contributions (pull requests, issues, and discussions) should follow these rules:
-
You should read through the Wiki to understand the project features and how to use it properly. This is to respect the time of the project's developers and maintainers and to save their energy for other problems that really need to be resolved.
-
Use the latest release version. If your contribution involves code/documentation changes, update to the latest version of the default (
master) branch. -
Avoid making duplicate contributions by searching for existing issues / discussions / pull requests, but don't leave any unhelpful comments such as "I have the same problem". Prefer using reactions if you simply want to "+1" an existing issue.
-
DO NOT email or tweet the project developers and maintainers directly, everything about the project should be left on GitHub.
Tip: If you are new to the open-source community, then please read through "How To Ask Questions The Smart Way" before contributing.
We expect every reasonable question you ask to be answered appropriately. If you want a quick and timely response, please ask questions at Jekyll Talk and StackOverflow, where there are tons of enthusiastic geeks who will positively answer your challenging questions.
If you can't get an answer in any of the above ways, then create a new discussion. As long as it is not a duplicate and RTFM / STFW issue, we will respond as soon as possible.
A great way to contribute to the project is to send a detailed issue when you encounter a problem. We always appreciate a well-written, thorough bug report.
-
Please figure out why the bug occurred, or locate the module in the project that caused this bug. Otherwise, there is a high probability that you are using/setting it incorrectly.
-
If the issue is caused by you modifying the project code or some configuration of Jekyll, then please DO NOT report such "bugs". Chirpy is an open-source project, but that doesn't mean we will maintain other specific forks (such as yours). You can learn about Jekyll and modern Web development to solve problems caused by custom modifications.
-
Make good use of your browser's incognito mode to troubleshoot if the problem is caused by caching.
-
As a last option, you can create a new Bug Report following the template to describe the details. If possible, providing a demo that reproduces the error will help us troubleshoot faster.
Feature requests are welcome! While we will consider all requests, we cannot guarantee your request will be accepted.
We want to avoid chaos in the UI design and therefore do not accept requests for changes like color schemes,
fontfamilies, typography, and so on. We want to avoid feature creep and focus only on the core features.
If accepted, we cannot make any commitments regarding the timeline for implementation and release. However, you are
welcome to submit a pull request to help!
If your request is about an enhancement, it is recommended to first submit a Feature Request to discuss whether your idea fits the project. See also: "Suggesting a New Feature". Other than that, you can start the PR process.
- Fork this project on GitHub and clone your repository locally.
- Setting up the development & test environments.
- Creating a new branch from the default branch and give it a descriptive name (e.g.
add-a-new-featorfix-a-bug). When development is complete, create a Conventional Commit with Git. - Submitting a Pull Request.