On Tue, Aug 21, 2018 at 11:24 AM, Josh Elser <els...@apache.org> wrote: > On 8/21/18 12:15 PM, Sean Busbey wrote: >> >> On Tue, Aug 21, 2018 at 11:03 AM, Josh Elser <els...@apache.org> wrote: >>> >>> Summarizing my feelings: A first-step might be to inch towards some >>> middle >>> ground where we allow code-review via PRs, but we still require a Jira >>> issue >>> and a patch to trigger QA (and avoid authorship issues, release note >>> issues, >>> etc) to "gate" the commit. >>> >>> That gives us clear next steps: >>> 1) Once QA works for PRs automatically, we can remove patch step >>> 2) Once Yetus doc-maker can pull from GH, we can skip Jira issues >>> ... >>> >>> There's some precedence here with already allowing reviewboard and >>> phabricator (in my mind). I would be OK with doing code-review on GH and >>> would personally prefer it over all other tools at our disposal. >>> >> >> >> We already do this today. As with review board and phabricator it >> mostly depends on the reviewer(s) you have or want. >> >> For example, when I work on significant doc changes now I put up a PR >> because that's how Misty likes to do reviews. >> >> That said, currently the folks who pay attention to outstanding PRs (I >> think maybe me and Chia-Ping?) mostly focus on pushing folks to JIRA >> and/or closing out unresponsive folks. > > > Oh, we do? I was under the impression that PRs were largely just told "File > a Jira and attach changes as a patch" for HBase. I guess I'm ignorant of > something that we already "support"?
PRs that show up without a JIRA associated with them are told that we rely on JIRA for tracking issues and they'll need to create a JIRA issue before having a PR. I haven't crunched the actual numbers yet, but my intuition is that the majority of folks who are given this feedback never return and their issue is eventually closed as inactive. I believe the folks who currently do the work of posting feedback to PRs that don't have a JIRA also happen to prefer using JIRA for review, so we tend to direct folks to post their change there at the same time. Doing it as a second step after they've made a JIRA would probably kill off any remaining enthusiasm, but we could probable rephrase how we present that so that it's clearer that it's optional.
