Do you accept patches / features to the Core, or is the code open source only in the sense “you may look at it”? And if you do accept features — perhaps on the case by case basis — what is the correct process? Proposal, Proposal with rough PR, or what would you prefer?
1 Like
That’s a good reminder to add a contributing document to our repo.
Bugfixes
Patch PRs are always welcome! Please keep them very focused on a single bug and solution for it. Don’t mix multiple bug fixes in a single PR. This will make it easier for us to review the fix and merge it.
Always send bug fix PRs to the develop branch – not master! Add a nice description of what it does if the PR is not self-explanatory. Ideally, every bug fix should also be combined with a unit test if possible, to avoid future regressions. Let us know if you need help with that.
Make sure that your version is up to date with the latest state on the develop branch and that you rebase changes before you send the PR.
You should also fix code style issues with PHP CS before you submit the PR if possible. Install PHP CS globally via composer and then run composer fix in the kirby repo.
Feature PRs
Feature PRs should be created on a new feature branch. Something like feature/adams-feature-x. Please have a look at the ideas repository https://github.com/getkirby/ideas/issues Maybe your feature idea already exists there and you can get valuable feedback from other users.
Here are some additional rules:
- New features must have unit tests
- Fix code style issues before you submit the PR
- Add a nice description
- Focus on a single feature per PR. Don’t mix features.
- Make sure you use a feature branch and you don’t send the PR to develop or master
- Write human-readable commit messages
Please understand that we might not be able to merge all feature ideas or that it might take a while. Features will also have to wait at least until the next feature release. Check out the roadmap to see upcoming releases: https://roadmap.getkirby.com
I hope this helps.
2 Likes