-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Create a CONTRIBUTING doc #307
Comments
#313 Adds templates to the repository for filing issues and creating PRs |
Question: How to handle commits? Especially when creating PRs, what kind of commit style do you prefer? Many small commits or one big squashed commit? Also, during code reviews, is it better to make multiple commits until resolution - squash then or don't squash at all? |
We have no issues with contributors making multiple commits in a PR. When the PR is finally merged it will be squashed into a single commit. |
Thanks! Unfortunately more questions come to my mind. Whats the current process dealing with 'old' issues which are still open but where a PR was merged which closes the issue? Also, how are new feature requests/questions handled? Some, smaller things, are kind of handled straight forward - what I observe. What about more structural things? Is there a vision, some kind of overall goal where SceneBuilder shall develop to? |
Hi @Oliver-Loeffler , Great questions. A clean up of issues and PR is due since we moved the repository to Github. #34 is a great example of why its high time :) Scene Builder is in great shape and it does what it is meant to do. Gluon is trying to maintain it, quash bugs and accept any community contribution. Similar to OpenJFX. As you have already noticed, smaller PRs are easy to review and therefore gets in quickly. Larger PR or any new features are difficult to review and therefore takes time. If you have any suggestions to the overall process, please let us know. |
How about something like this, I just repurposed one for FXGL How to contribute to scenebuilderContribution of any form is welcome! Please see the list below on how you can contribute to the project. Once you've decided what you would like to do, let us know about it first in the Discussions section (this needs creating...). This is just to make sure that the issue you want hasn't already been implemented, fixed or being worked on in newer versions. Any new API or changes to existing API should be discussed to avoid inconsistencies.
Any Pull Request should follow the provided template. All Pull Requests will be reviewed in accordance with the Code of Conduct (this needs creating...) |
Good idea. A few remarks:
|
|
Currently we have 2 issue templates, bug and feature request. How about refactorings? If we would like to discuss changes before a PR is started and if we'd like to increase number of tests and test coverage, a refactoring issue template could help. |
Public one-off refactorings tend to lead to long review times, so here a template eventually could be useful. As for long-term contributors, to expedite the process, at least in the short term, we could agree certain rules, such as refactorings should not affect multiple files or be complex (whatever the definition of this is). As I learn the codebase, most of my PRs in the short term will be small tweaks in the |
We need to be more clear about how people can contribute. We should be very open to issues, PR's and reviews, but the process needs to be clear.
In general, a PR should refer to an issue, and it should contain a test that fails before the patch, and succeeds after the patch. Also, we should provide guidelines for PRs, so that the review process becomes slightly simpler.
The text was updated successfully, but these errors were encountered: