...
This is documented in the Sling Aggregator Github module.
Gitiquette
Force pushing to the master branch, or to other branches that are shared with others, is discouraged. It makes collaboration harder and potentially impacts other tools as well - Jenkins, SonarCloud, etc. If you need time experimenting and fiddling with history, it's better to start working with an individual repository and then bring it to Sling, once it's stable.
Merging pull requests from contributors
Maintaining a linear history in git is preferred, especially for small contributions. To that end, we should always rebase + merge commits on GitHub instead of merging them ( which creates a merge commit ).
Each commit should be buildable and correct by itself, as much as possible. Therefore, when asking contributors for revisions to small contributions (1 commit) we should ask them to amend the and force-push the commit so that they do not create multiple artificial commits. This is beneficial when reviewing history for changes and also when running git bisect . Unfortunately it is not possible to rebase + squash + merge using the GitHub UI, so we need to either ask the contributors to amend + force-push, or to perform these operations locally.
It is also important to maintain the original author of the pull request, giving them credit for their contribution. This is also useful when compiling various contribution metrics, e.g. in Kibble.
Accepting new significant contributions
When accepting an external contribution we will import it into the sling-whiteboard repository. Before making a new release, we will move it to its own repository with the release manager also proposing a proper artifact id and therefore repository name.
...