Contributing to Jupyter Book#

Welcome to the jupyter-book repository! We’re excited you’re here and want to contribute.

These guidelines are designed to make it as easy as possible to get involved. If you have any questions that aren’t discussed below, please let us know by opening an issue!

Before you start you’ll need to set up a free GitHub account and sign in. Here are some instructions.

Already know what you’re looking for in this guide? Use the TOC to the right to navigate this page!

Joining the conversation#

jupyter-book is a young project maintained by a growing group of enthusiastic developers— and we’re excited to have you join! Most of our discussions will take place on open issues.

As a reminder, we expect all contributors to jupyter-book to adhere to the Jupyter Code of Conduct in these conversations.

Contributing through GitHub#

git is a really useful tool for version control. GitHub sits on top of git and supports collaborative and distributed working.

You’ll use Markdown to chat in issues and pull requests on GitHub. You can think of Markdown as a few little symbols around your text that will allow GitHub to render the text with formatting. For example you could write words as bold (**bold**), or in italics (*italics*), or as a link ([link](https://https://youtu.be/dQw4w9WgXcQ)) to another webpage.

GitHub has a helpful page on getting started with writing and formatting Markdown on GitHub.

Understanding issues, milestones and project boards#

Every project on GitHub uses issues slightly differently.

The following outlines how the jupyter-book developers think about these tools.

Issues are individual pieces of work that need to be completed to move the project forwards. A general guideline: if you find yourself tempted to write a great big issue that is difficult to describe as one unit of work, please consider splitting it into two or more issues.

Issues are assigned labels which explain how they relate to the overall project’s goals and immediate next steps.

Issue labels#

The current list of labels are here and include:

  • Help Wanted These issues contain a task that a member of the team has determined we need additional help with.

    If you feel that you can contribute to one of these issues, we especially encourage you to do so!

  • Good First Issue These issues contain a task that a member of the team thinks could be a good entry point to the project.

    If you’re new to the jupyter-book project, we think that this is a great place for your first contribution!

  • Bugs These issues point to problems in the project.

    If you find new a bug, please give as much detail as possible in your issue, including steps to recreate the error. If you experience the same bug as one already listed, please add any additional information that you have as a comment.

  • Enhancement These issues are asking for enhancements to be added to the project.

    Please try to make sure that your enhancement is distinct from any others that have already been requested or implemented. If you find one that’s similar but there are subtle differences please reference the other request in your issue.

  • Question These are questions that users and contributors have asked.

    Please check the issues (especially closed ones) to see if your question has been asked and answered before. If you find one that’s similar but there are subtle differences please reference the other request in your issue.

Repository Structure of Jupyter Book#

This section covers the general structure of the Jupyter Book repository, and explains which pieces are where.

The Jupyter Book repository contains two main pieces:

The command-line tool and Python package#

This is used to help create and build books. It can be found at ./jupyter_book.

  • The page module builds single pages. This module is meant to be self-contained for converting single .ipynb/.md/etc pages into HTML. Jupyter Book uses this module when building entire books, but the module can also be used on its own (it’s what jupyter-book page uses). You can find the module at: jupyter_book/page.

  • The create.py and build.py create and build a book. They connect with the CLI and are used to process multiple pages and stitch them together into a static website template.

The template SSG website#

This is used when generating new books. This website defines the structure of the site that is created when you run jupyter-book create. It contains the Javascript, CSS, and HTML structure of a book. It can be found at jupyter_book/book_template.

  • The _includes/ folder contains core HTML and javascript files for the site. For example, _includes/head.html contains the HTML for the header of each page, which is where CSS and JS files are linked.

  • The assets/ folder contains static CSS/JS files that don’t depend on site configuration.

  • The _sass/ folder contains all of the book and page CSS rules. This is stitched together in a single CSS file at build time (SCSS is a way to split up CSS rules among multiple files). Within this folder, the _sass/page/ folder has CSS files for a single page of content, while the other folders/files contain CSS rules for the whole book.

  • The content/ folder contains the content for the Jupyter Book documentation (e.g., the markdown for this page).

An example#

Here are a few examples of how this code gets used to help you get started.

  • when somebody runs jupyter-book create mybook/, the create.py module is used to generate an empty template using the template in jupyter_book/book_template/.

  • when somebody runs jupyter-book build mybook/, the build.py module to loop through your page content files, and uses the page/ module to convert each one into HTML and places it in mybook/_build.

Hopefully this explanation gets you situated and helps you understand how the pieces all fit together. If you have any questions, feel free to open an issue asking for help!

Making a change#

We appreciate all contributions to jupyter-book, but those accepted fastest will follow a workflow similar to the following:

1. Comment on an existing issue or open a new issue referencing your addition.

This allows other members of the jupyter-book development team to confirm that you aren’t overlapping with work that’s currently underway and that everyone is on the same page with the goal of the work you’re going to carry out.

This blog is a nice explanation of why putting this work in up front is so useful to everyone involved.

2. Fork the jupyter-book repository to your profile.

This is now your own unique copy of jupyter-book. Changes here won’t effect anyone else’s work, so it’s a safe space to explore edits to the code!

Make sure to keep your fork up to date with the master repository.

3. Make the changes you’ve discussed.

Try to keep the changes focused. We’ve found that working on a new branch makes it easier to keep your changes targeted.

4. Submit a pull request.

A member of the development team will review your changes to confirm that they can be merged into the main code base. When opening the pull request, we ask that you follow some specific conventions. We outline these below.

Pull Requests#

To improve understanding pull requests “at a glance”, we encourage the use of several standardized tags. When opening a pull request, please use at least one of the following prefixes:

  • [BRK] for changes which break existing builds or tests

  • [DOC] for new or updated documentation

  • [ENH] for enhancements

  • [FIX] for bug fixes

  • [REF] for refactoring existing code

  • [STY] for stylistic changes

  • [TST] for new or updated tests, and

You can also combine the tags above, for example if you are updating both a test and the documentation: [TST, DOC].

Pull requests should be submitted early and often!

If your pull request is not yet ready to be merged, please open your pull request as a draft. More information about doing this is available in GitHub’s documentation. This tells the development team that your pull request is a “work-in-progress”, and that you plan to continue working on it.

When your pull request is Ready for Review, you can select this option on the PR’s page, and a project maintainer will review your proposed changes.

Recognizing contributors#

We welcome and recognize all contributions from documentation to testing to code development. You can see a list of current contributors in the contributors tab.

Thank you!#

You’re awesome.


— Based on contributing guidelines from the STEMMRoleModels project.