I don't think a ticket per pull request is appropriate for things like typos, modifications to documentation, simple modifications to the CI environment, or to code comments. For example if I move the bionic build jobs from go 1.11.4 to 1.11.5, that should not require a ticket. It's just noise in release notes.
- Jim On Sat, Feb 16, 2019 at 12:57 PM Jens Geyer <jensge...@hotmail.com> wrote: > 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 > > > >
