Jekyll is a static site generator. It takes raw text files (e.g. Markdown), applies a template elements (e.g. custom CSS), and returns a ready-to-publish website. Getting started with Jekyll is easy, see the quick-start guide.
The basic directory structure is described in the Jekyll documentation.
Markdown files (either .md or .markdown) in the top level directory are added to the sidebar automatically.
Since this site isn't a blog per se, the
_posts directory contains the Markdown files for the "News" on the index page.
We welcome contributions from anyone. Since the code is on GitHub (hint: you're already here) you've got access to everything you need to make changes.
Create an issue
If you find a bug in the site (and you don’t know how to fix it) or have an idea for a new feature.
If you’re able to patch the bug or add the feature yourself – fantastic, make a pull request with the code!
Additionally if there is content you'd like to see here (e.g. a dedicated page for X) the best thing to do is submit the content as a pull request.
Pull request pro tips
Try to follow these pro tips from the GitHub Pages guide:
- Fork the repository and clone it locally. Connect your local to the original ‘upstream’ repository by adding it as a remote. Pull in changes from ‘upstream’ often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. See more detailed instructions here.
- Create a branch for your edits.
- Be clear about what problem is occurring and how someone can recreate that problem or why your feature will help. Then be equally as clear about the steps you took to make your changes.
- It’s best to test. Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don’t break the existing project.
- Include screenshots of the before and after if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
- Contribute in the style of the project to the best of your abilities. This may mean using indents, semi colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.