-
Notifications
You must be signed in to change notification settings - Fork 448
Contribution Guide
Documentation Style Guide is also under construction.
The Accessible Contributions page lists newcomer-friendly issues that I would like help on.
You'll need to make you're own fork of flixel, do so by clicking this button in the top right of the page.
I recommend cloning the flixel repo via git clone https://github.com/HaxeFlixel/flixel.git
, and then adding your fork as a new remote. Here's an example of how user @Geokureli added their fork as a unique remote, labelled "geo"
git remote add geo https://github.com/geokureli/flixel.git
When people submit PRs to flixel, we often add their fork to our local repo (outlined above), so that we can check out, test and make changes. It is Not only harder to keep track of branches if they are all named "dev" but we are often not allowed to make changes to the dev branch of other repos, unless specifically added. If you make a new feature branch off of flixel:dev by default flixel contributers are allowed to push changes to it.
Making new branches is easy in vscode's github ui, or in most desktop Git UI clients, or you can use Git's command line interface, like so (make sure you are on the flixel:dev branch before running these commands)
git checkout -B new-branch
git push --set-upstream geo new-branch
Create a small test state that highlights the change, fix or feature you wish to merge. Every pull request will trigger Github checks which compile and run unit tests, coverage tests, demos and snippets, and this can often notify us that something was unintentionally changed or broken, but it's not perfect. We still manually verify every change, so if you don't create a test, we will, when we have time. Here's an example of test states created to test haxeflixel changes, some of them provide a link to the PR, too.
Only submit features that you have a practical use for, or features that you have used in other frameworks. Please, do not submit features that you think people will "theoretically" need. Most of the rejected feature PRs to flixel are from people who, when asked, cannot even produce a practical use-case of their own feature. If you are new to open-source development and you think a feature would help flixel, I recommend making a proprietary version in a personal project, releasing that in your own public repo, see how others intend to use it and then, once it has been battle-tested, try adding it to flixel or flixel-addons.