Exempt feature branches from the 24 hour delay for merging

[nhorman]

Because our feature branch policy indicates that the merge of a feature branch to the master branch requires a separate PR, it seems like it might be prudent to exempt PR's targeting the feature branch from the same 24-hour delay. Providing this extension would allow for faster development cycles when constructing new features

[t8m]

I do not think this change is necessary and that policy about having a separate PR when merging the feature branch alleviates the need for this. 24 hours delay is fairly short and in my opinion it is not the source of any slowdown. Also the delay does not need to be enforced on last minute trivial fixups on a PR that was already in approved: done state for 24 hours. I.e. - someone notices there was a typo in a comment or documentation during the 24 hours period, the fixup needs to be re-approved but the 24 hours window does not need to be restarted.

[mattcaswell]

All code needs to be properly reviewed before it goes into the codebase. The 24 hour timer is there to ensure that people have sufficient time to see changes before they get merged. Prior to introducing that policy we had problems where PRs got merged very quickly without people having the opportunity to see the changes at all. This had a detrimental impact on our quality. I don't really see the feature branches as fundamentally different to master or a stable branch. The PR is our opportunity to review a proposed changed. Once its merged we're not going to go back and review it again. So I'm not really seeing the argument to have a different policy between master and the feature branches.