Hi JB, Yes François Papon has suggested the same in the slack channel. I will probably based it on the Shiro one. I think this is a really good way of addressing this problem.
Regards, Serge... On Wed, Feb 10, 2021 at 1:55 PM Jean-Baptiste Onofre <[email protected]> wrote: > 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 > >
