No one person can make an amazing tracker - that's why you can help make it better! From code, to data, or images: all contributions are welcome! When you contribute, you need to follow some guidelines.
Before you submit an issue, please search the issues page for open and closed issues. Your issue may have already been reported and discussion already started.
In order to get your issue fixed as quickly as possible, when you submit an issue, please provide a save file of your tracker (Cogwheel -> Application -> File -> Save or Ctrl+S) and your seed settings string.
Please note: issues that remain inactive for extended periods of time may be closed if there's no response from the reporter.
If you would like to fix a bug, you may submit a pull request instead.
You may request a new feature by submitting an issue to this repo. After a feature request has been opened and reviewed, if accepted, work can be tracked via the project board.
If you would like to implement a new feature, you may submit a pull request instead.
This guide assumes that you have a working git installation. If you are completely new to git and source code repositories, it's highly recommended that you read Github's Git Guides. The Git Guides describe in detail how to install, configure, and use git.
You can also edit files in Github's Web UI by clicking the pencil icon at the top right of any file.
- Fork the repo.
- In your forked repository, switch to a new branch:
git switch -c my-branch-name main - Make your changes.
- Commit your changes using a descriptive commit message that follows the commit message guidelines:
git commit --all - Push your branch:
git push origin my-branch-name - On Github, send a pull request to
pmr_map_tracker:main.
If a reviewer has asked for changes, then:
-
Make any updates that were requested.
-
Create a fixup commit and push to your Github repo (this will auto-update your PR):
git commit --all --fixup HEAD git pushIf you're not using git on the command line, the only thing that differentiates a fixup commit from a regular commit is prepending:
fixup!(notice the space) to the original commit message's header.If you want to know more about fixup commits, AngularJS's documentation has a great write-up about them.
A reviewer might suggest changes to the commit message, like adding more context to a change or editing to adhere to the commit message guidelines. In order to update the commit message of the most recent commit on your branch:
- Check out your branch.
git checkout my-branch-name - Amend the last commit and change the message:
git commit --amend - Push to your repository (this will auto-update your PR):
git push --force-with-lease
If you need to update the commit message of an earlier commit, you can use git rebase -i to interactively rebase your branch allowing you to reword previous commits.
Instructions to interactively rebase for GUI git applications differ depending on the program.
Once your PR is merged into main, you can safely delete your local branch and pull your changes into your local clone.
- Delete the remote branch on Github via the web UI or via your shell:
git push origin --delete my-branch-name - Checkout the main branch
git switch main -f - Delete your local branch
git branch -D my-branch-name - Pull the latest from upstream
git pull --ff upstream main
It's best to keep things simple, but there's one thing that that's required when contributing. This repository requires contributors to follow precise rules for commit messages as it helps develop an easier to read commit history.
A good commit message not only explains the what but also the why; your submitted code will explain the how.
This repo follows a commit message structure inspired by multiple open-source software projects and standards.
<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is required and must follow the message header format. Try to keep the header under 50 characters; Github knows about this convention and the web UI will notify you when you've gone over.
You can think of your header as a shortened form of the sentence:
"This is a
<type>commit, regarding [the]<scope>; it will<short summary>."
The body is optional; if included, should be at least 20 characters. Please consider adding a commit message body, as it will allow you to explain why you made this change and your motivations behind the change. Messages in bug fix commits are especially useful if they contained information about the behavior before the change.
The footer is optional; if included, can contain links to issues that this commit will close. You can close a PR via commit message with words like fix, fixes, close, or closes, followed by the issue number prefixed with a #: for example, fixes #14.
<type>(<scope>): <short summary>
| | |
| | └─≫ summary in present tense, not capitalized, no period at the end.
| |
| └─≫ commit scope: prlg|ch1|ch2|ch3|ch4|ch5|ch6|ch7|ch8|
| checks|items|layouts|logic|map|scripts
|
└─≫ commit type: chore|docs|feat|fix|refactor
Type is required and must be one of the following:
chore: changes that do not touch any user-facing code, ex. repo settings, templates, etc.docs: changes that involve updating documentation likeREADME.mdorCHANGELOG.md.feat: a new featurefix: a bug fixrefactor: a change that is neither a new feature nor a bug fix
Scope is optional and if supplied, should be the area your change affects. Use logic for generalized logic fixes, like a new randomization option, or logic overhaul; the ch<#> scopes for fixes targeting a specific chapter; or any of the other scopes for generalized changes.
If your PR reverts a previous commit, simply add revert: (note the space) to the beginning of the header of the commit you're reverting.
This example starts a new line before reaching 72 characters (or columns); line wrapping at 72 characters is not required, this is a legacy style for users who still primarily use command-line utilities (80 columns is the default terminal width in Linux).
feat(logic): add koopa koot shuffle support
Adds koopa koot shuffle support with a progressive item that denotes
the current koopa koot step. Standard logic ties the items to their
relevant checks.
A progressive item was chosen instead of individual flags to reduce
complexity and because the rando dev team is not currently randomizing
the steps themselves. If the steps themselves were to be randomized,
this would need to be refactored.
Closes #123