<div dir="ltr">When we added commit validation to our CI, we created a loophole that would allow small changes like typo fixes to not have a redmine issue or changelog entry. By having '[noissue]' in the commit message, users could bypass our commit requirements. However, this loophole is not being used as intended--it's being used for all sorts of changes from new features to bug fixes. <div><br></div><div>This is going to be a major problem for users and plugin writers when we release 3.0 and they start to upgrade from release to release. These [noissue] changes won't being reflected in our changelog which invalidates the motivation behind having a changelog.<div><br></div><div>My first inkling is to remove the '[noissue]' functionality. Other projects like Katello and foreman already do this. If you don't want your change reflected in the changelog, you should be creating .misc entries for these changes in the CHANGES folder. The downside to this is every change will require a changelog and issue, and this creates extra steps for devs and contributors.</div><div><br></div><div>Another option is to make our check smarter by incorporating some other condition(s) or metric(s). For example, perhaps we could allow [noissue] changes only to certain directories like our tests directory. The problem here is getting the parameters right. What sorts of changes changes should we allow to be [noissue] ones? I've thought about this a bit and couldn't think of a good set of criteria.</div><div><br></div><div>Thoughts?</div><div><br><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>David<br></div></div></div></div></div></div></div></div></div></div></div>