Hi all, a few days ago Jim raised the question about the policy regarding JIRA tickets. As I am not fully happy with either solution we practiced so far, I gave it a second thought.
So here’s my proposal: 1. We have one ticket per patch or pull request. 2. Minor changes may be put into one patch/PR. The first part should be obvious, so let me focus on the second point. Larger changes should still be split into multiple Patches / PRs, because they usually come with their own language specific discussion, problems, implermentation details and last not least test cases. In contrast, if a patch is quite minorish and affects a lot of languages needing a 3-liner fix in (basically) the same way, there is no point in creating 20 tickets just for the sake of having them. A larger patch is defined by “changes that cannot easily be managed/commented/reviewed by one single person as a whole”. Yes, that’s a vague criterion, but it should only serve as a “intended outcome” kind of guide. The whole idea is to reduce unnecessary administrative overhead where possible, but split up matters where necessary. That’s what I want to achieve. Could that work for us? Are there any objections? Other (maybe better) ideas? Have fun, JensG