This guide is for maintainers. These special people have write access to one or more of Jekyll’s repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
All pull requests should be subject to code review. Code review is a foundational value of good engineering teams. Besides providing validation of correctness, it promotes a sense of community and gives other maintainers understanding of all parts of the code base. In short, code review is crucial to a healthy open source project.
Read our guide for Reviewing a pull request before merging. Notably, the change must have tests if for code, and at least two maintainers must give it an OK.
We have a helpful little bot which we use to merge pull requests. We don’t use the GitHub.com interface for two reasons:
History.markdownfile for each release
To merge a pull request, leave a comment thanking the contributor, then add the special merge request:
Thank you very much for your contribution. Folks like you make this project and community strong. :heart: @jekyllbot: merge +dev
The merge request is made up of three things:
@jekyllbot:– this is the prefix our bot looks for when processing commands
merge– the command
+dev– the category to which the changes belong.
The categories match the headings in the
History.markdown file, and they are:
+major) – major updates or breaking changes to the code which necessitate a major version bump (v3 ~> v4)
+minor) – minor updates (with the labels
enhancement) which necessitate a minor version bump (v3.1 ~> v3.2)
+bug) – corrections to code which do not change or add functionality, which necessitate a patch version bump (v3.1.0 ~> v3.1.1)
+doc) - changes to the documentation found in
+site) – changes to the source of https://jekyllrb.com found in
+dev) – changes which do not affect user-facing functionality or documentation, such as test fixes or bumping internal dependencies
+port) — bug fixes applied to a previous version of Jekyll pulled onto
master, e.g. cherry-picked commits from
Once @jekyllbot has merged the pull request, you should see three things:
History.markdownfile which adds a note about the change
If you forget the category, that’s just fine. You can always go back and move the line to the proper category header later. The category is always necessary for
jekyll/jekyll, but many plugins have too few changes to necessitate changelog categories.
You did it! Thanks for being a maintainer for one of our official Jekyll projects. Your work means the world to our thousands of users who rely on Jekyll daily.