Hi Serge, I fully agree. What about adding a PR template ?
We can create: .github/PULL_REQUEST_TEMPLATE.md Containing some guideline for the PR. For instance: **Please** add a meaningful description for your change here ------------------------ Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily: - [ ] [**Choose reviewer(s)**](….) and mention them in a comment (`R: @username`). - [ ] Format the pull request title like `[UNOMI-XXX] Fixes bug in foo`, where you replace `UNOMI-XXX` with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue. - [ ] If this contribution is large, please file an Apache [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). See the [Contributor Guide](https://unomi.apache.org/contribute) for more tips on [how to make review process smoother](https://unomi.apache <https://unomi.apache/>.org/how-to). Regards JB > Le 10 févr. 2021 à 13:32, Serge Huber <[email protected]> a écrit : > > Hi Unomi-fans. > > I’d like to discuss something about PRs. I think it would be great if we > could agree on a minimum of process because I’m struggling with managing > the project without it. Ideally for each PR I’d love to have: > > - An associated JIRA ticket and using the JIRA reference in the PR title > (UNOMI-XXX This is the PR title). This is because the changelogs are > generated from JIRA as well as the roadmap is also managed this way. We can > maybe look at improving this down the line but right now it is something > that is needed for any changes to the code. If they are changing to the > project (build config etc) this is not needed. Also documentation changes > could simply refer a global JIRA or none at all. Note that it is perfectly > fine to use the same JIRA for multiple PRs if it is relevant. > > - When possible (relatively easy), adding integration tests is a BIG plus. > This is especially true for code that is destined to be added in stable > branches. I’m not saying that I’d like to require this but I think that if > there is a potentially breaking change an integration test would go a long > way making sure there are no regressions and that the new code is working > properly > > - Proper descriptions of what the changes do and why they are needed. Here > no need to have to put much but just enough so that we don’t have to read > the code to understand what it is and why it is needed. Globally the PRs do > this but some don’t. It’s also perfectly fine to copy-paste descriptions > between JIRA and PR. > > So these are my thoughts. I’d love to hear your thoughts as to whether this > sounds reasonable or not. If not I’m more than willing to discuss it but > the main idea is to have some common way of working. > > Best regards, > Serge > Apache Unomi PMC chair
