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
