👾 🎉 Thank you for contributing to the project! 🎉 👾
The following is a set of guidelines for contributing to the project on GitHub. These are mostly guidelines, not rules. Use your best judgment and feel free to propose changes to this document in a Pull Request.
Table of Contents:
- 💜 Code of Conduct
- ❓ What should I know before I get started?
- 🎁 How can I contribute?
- 🎨 Styleguides
- 📓 Additional Notes
This project and everyone participating in it is expected to abide by and uphold the Code of Conduct. Please report any unacceptable behaviour to Dr Sarah Gibson.
This repository (https://github.com/sgibson91/bump-jhub-image-action) is specifically designed to check if Docker images that provide computational environments for a given JupyterHub deployment are up-to-date with the most recent tags published on a container registry.
This project is mostly a Python wrapper around HTTP requests to the GitHub REST API, with some YAML/JSON handling.
If something doesn't work the way you expect it to, please check it hasn't already been reported in the repository's issue tracker.
Bug reports should have the bug label, or have a title beginning with [BUG].
If you can't find an issue already reporting your bug, then please feel free to open a new issue. This repository has a bug report template to help you be as descriptive as possible so we can squash that bug! 💪
If there was something extra you'd like to see added, please check that the feature hasn't already been requested in the project's issue tracker.
Feature requests should have the enhancement label.
Please also check the closed issues to make sure the feature has not already been requested but the project maintainers decided against developing it.
If you find an open issue describing the feature you wish for, you can "+1" the issue by giving a thumbs up reaction on the top comment of the issue. You may also leave any thoughts or offers of support as new comments on the issue.
If you don't find an issue describing your feature, please open a feature request. This repository has a feature request template to help you map out the feature you'd like.
Unsure where to start contributing?
Check out the 
A Pull Request is a means for people to collaboratively review and work on changes before they are introduced into the base branch of the code base.
To prepare your contribution for review, please follow these steps:
- Fork this repository
- Create a new branch on your fork
- Where possible and appropriate, please use the following convention when naming your branch:
<type>/<issue-number>/<short-description>. For example, if your contribution is fixing a a typo that was flagged in issue number 11, your branch name would be as follows:fix/11/typo.
- Where possible and appropriate, please use the following convention when naming your branch:
- Make your changes!
- Open your Pull Request
- This repository has a pull request template which will help you summarise your contribution and help reviewers know where to focus their feedback. Please complete it where possible and appropriate.
Congratulations! 🎉 You are now a developer for the project! 👾
The maintainers will then review your Pull Request and may ask for some changes. Once you and the maintainers are happy, your contribution will be merged!
When writing Python scripts for this repository, it is recommended that contributors use black, flake8 and isort for formatting/linting styles and sorting imports. The repository has GitHub Actions to check files are conforming to this styleguide, though not doing so will not prevent your contribution from being merged. These tools are used as the maintainers believe this makes the code easier to read and keeps consistent formatting as more people contribute to the project.
While flake8 commands can be disabled, we only recommend doing this for specific lines in such cases where reformatting would produce "ugly code". The maintainers retain final say on what is "ugly code" on a case-by-case basis.
When adding or updating a Python function, we recommend using static typing and type hints where appropriate. The maintainers encourage this practice since they believe it makes the code easier to read and understand, and explicitly defines what inputs and outputs a function may produce.
While type hints do not affect the code at runtime, the project does implement GitHub Actions to run mypy to check the code conforms to the declared type hints.
Documentation files are written in Markdown.
When writing Markdown, it is recommended to start a new sentence on a new line and define a new paragraph by leaving a single blank line. (Check out the raw version of this file for an example!) While the sentences will render as a single paragraph; when suggestions are made on Pull Requests, the GitHub User Interface will only highlight the affected sentence - not the whole paragraph. This makes reviews much easier to read!
Issues and Pull Requests can have labels assigned to them which indicate at a glance what aspects of the project they describe. It is also possible to sort issues by label making it easier to track down specific issues. Below is a table with the currently used labels in the repository.
| Label | Description |
|---|---|
 |
Something isn't working |
 |
Improvements or additions to the documentation |
 |
New feature or request |
|
Good for newcomers |
|
Extra attention is needed |