Ok I've created a PR for the pull request template (can we make this more recursive ?) :))
https://github.com/apache/unomi/pull/250 Please don't hesitate to give me feedback, I want to make this as useful as possible. Regards, Serge Huber. On Wed, Feb 10, 2021 at 4:41 PM Serge Huber <[email protected]> wrote: > 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 >> >>
