I wouldn't go for #3 and always require a JIRA for a PR. In general, I think we should state the best practices for using GitHub PRs. There were some guidelines but they were kind of open For example, adding always a link to the JIRA to the description. I think PRs can have a template as a start.
The other thing I would do is to disable the automatic Jenkins trigger. I've seen the "retest this" and others: https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin https://github.com/jenkinsci/ghprb-plugin/blob/master/README.md On Tue, Aug 27, 2019 at 10:47 AM Wei-Chiu Chuang <weic...@apache.org> wrote: > Hi, > There are hundreds of GitHub PRs pending review. Many of them just sit > there wasting Jenkins resources. > > I suggest: > (1) close PRs that went stale (i.e. doesn't compile). Or even close PRs > that hasn't been reviewed for more than a year. > (1) close PRs that doesn't have a JIRA number. No one is going to review a > big PR that doesn't have a JIRA anyway. > (2) For PRs without JIRA number, file JIRAs for the PR on behalf of the > reporter. > (3) For typo fixes, merge the PRs directly without a JIRA. IMO, this is the > best use of GitHub PR. > > Thoughts? >
