Skip to content

Contribution Basics

Tony edited this page Jul 31, 2023 · 8 revisions

If you'd like to contribute to GDTemplate, the steps are generally straightforward. Note: this is not the steps for basic use, this is for people adding code to the project itself, rather than using it for their own game projects.

With Github Desktop (Win/Mac)

  1. Download Github Desktop
  2. Install the application and run some initial application setup.
  3. Navigate to https://github.com/programnoir/GDTemplate
  4. Use the green dropdown menu to open the project with Github Desktop.
  5. Complete adding the project to a dedicated development folder.

Adding a GPG signature key to your commits.

GDTemplate requires all commits to be signed before merging. Below is a very straightforward guide to setting this up:

Windows

  1. First, install GPG4Win, and include Kleopatra in the installation: https://www.gpg4win.org/download.html
  2. Next, open Kleopatra and generate a pair of keys.
  3. Right-click on the new key and "Export" it to a .asc file. Do NOT select "Export Secret Keys."
  4. Open the .asc file in a text editor like notepad and copy its contents.
  5. https://github.com/settings/keys -> New GPG Key -> Paste contents and give it a name.
  6. Once added, you'll see a Key ID listed for your GPG key. Take note of this Key ID.
  7. Open your command prompt and run git config --global --edit to edit your config file (you can't do this in Github Desktop yet).
  8. Edit your config file with this information and restart Github Desktop. Your code will now be signed and verified with Github.
[user]
  name = Firstname Lastname
  email = [email protected] (use the email you sign in with on github)
  signingkey = Paste your Key ID here
[gpg]
  program = gpg.exe
[commit]
  gpgsign = true
[tag]
  gpgsign = true

Mac

I don't have a mac, so I can't give a straightforward set of steps for generating your keys.

Creating a branch for development

  1. Navigate to issues and pick an existing issue.
  2. Assign it to yourself using the right-hand pane.
  3. In Github Desktop, ensure you have the GDTemplate repository selected.
  4. Under the branch menu, select "new branch."
  5. Select an up-to-date branch to base your contribution on (generally this won't be master).
  6. Name your branch and create it.

Contributing to the project with your branch.

  1. Make changes to the project.
  2. Return to Github Desktop and ensure that only the files you changed are being committed.
  3. After making a commit (left pane), you can then create a pull request.

Helping another person's pull request.

This is a rather new section so this may get updated with new info.

Testing/Performance Review

Testing reviews look for edge cases where a bug through normal use of the project's features can occur. It is recommended that you obtain the version of the project in the pull request's branch using Github Desktop. Instead of making a bug report in the issues section, leave a comment in the pull request thread asking for the developer to address the edge case. It should be clarified if you're making an opinion about how the feature should work in that case or if there is a bug where there was expected behavior and then unexpected behavior.

Translations/Code Style Adherence Review

Style adherence reviews can be more involved. It is recommended that you are familiar with gdscript before performing a style adherence review.

  1. On the right-hand panel of the pull request, add yourself as a reviewer.
  2. Navigate to the Files Changed tab. It is recommended that you open a tab with https://github.com/programnoir/GDTemplate/wiki/Coding-Style-Guidelines on the side.
  3. If you see a line of code in a .gd file that contains a violation of the code style guidelines, use the "+" button that appears while hovering over the line and click it to start a review and add a comment.
  4. Not all files will look the same, and some (such as .tscn files) are harder to parse than others. I recommend checking these in the editor via the testing/performance review process.