What you do with this theme or how you interpret it is up to you, but it will be your task to come up with something fun using this theme.
The chosen technology for this code jam is Kivy.
Kivy is a cross-platform framework for making user interfaces. We know that a lot of you are probably relatively new to this framework and that's why some of Kivy's core developers will be hanging out in the #winter-code-jam channel to help you!
Have your team leader fork the repository. If your leader is unavailable, it's okay if someone else does it.
Open a pull request from your fork's master to the master branch of this repository. This pull requests will eventually count as your team's submission, but make sure to open the PR when the code jam starts. You can use the name of your team as the name of the pull request.
Your own team's project files should be contained within your own team's subdirectory. A directory with your team's name will already exist, so make sure to use this.
Since you are making a pull request from the master of your fork, it would probably be best to use different branches in your repository to work on your project. You can then periodically merge those development branches into the master branch.
For an ideal developer workflow, you should probably be opening pull requests inside of your fork, targeting your own master branch. If this doesn't make any sense to you because you're not that well-versed in git, you will probably be okay with all of you just pushing code directly to your master branch, but keep in mind that this may lead to conflicts if you are all working in parallel.
The Pull Request you created originally will be automatically updated whenever you push code to master on your fork, so no need for updating anything yourself or creating a new Pull Request at the end. Just keep pushing code to your master branch and do your best to finish before the code jam ends!
Read these before starting any work on your projects.
Your team folder should already contain a README.md file that you should use to document your project. At the very least, make sure to include information on how to set up and run your project so the judges won't have trouble running it. Failure to provide this information may lead to losing points, or in extreme cases, disqualification.
We expect you to submit code that has a style that is in accordance with PEP8.
Pull requests to this repository will be automatically linted with a tool called flake8 (see below for more information). Your team folder contains a flake8 configuration file, .flake8, that allows you to run flake8 with the same settings as we will use.
We have set a maximum line length of 100 characters. This is also set and checked in the flake8 configuration.
If you wish to use an autoformatter like black, that is absolutely fine. Do note that most autoformatters do not guarantee that your code will pass flake8 and it's up to you to double check that.
You may use any third party package that's available on PyPI, but you should provide some form of method to easily install your project dependancies, such as a strictly pinned requirements.txt, a Pipfile, or some other form of dependency management list.
You should make no changes outside of your team's folder. This means that all of the files you want to include, including your code, assets and dependancy management files should all be contained that directory and not in the root level of the repository.
This ensures that we can merge your pull request into the repository once the Code Jam is over, you get GitHub contribution credit towards our organization and, most importantly, it will showcase your project on GitHub.
Code style and readability will be important factors in judging your team's project. We expect you to follow the style recommendations made in PEP8 and, to check for compliance with PEP8, we will use a linting tool called flake8. In case PEP8 and flake8 disagree, the output of the linter will be leading.
We will be using flake8 without additional plugins and with most of default settings enabled. The most notable exception is that we've set the maximum line length to 100 characters. To make it easy for you to run flake8 with the same settings as we will use, we have added a .flake8 configuration file to your team folder.
Obviously, adhering to PEP8 is not the only factor that determines if your code is readable, so make sure to look beyond PEP8 as well.
To help us check your code for compliance with PEP8, we have set up an automated build pipeline that will lint all pull requests made to this repository. Each time a pull requests is opened or when changes are made to the source branch (master on your team's fork) of a PR, the build pipeline will automatically lint the pull request. When the build process has completed, the build status will automatically be reported in the pull request:
Please note that you should not use this pipeline as a remote linter. Ideally, all changes made to the master branch of your team's repository have already been linted locally before they were pushed to the remote repository.
Our website contains some pages that may help you get started:
