Heya, and happy Friday. I would like to propose that we drop support for receiving contributions by way of attaching a patch file to a Jira issue. From my perspective, in the face of modern interfaces for PR-style review, this is an "archaic" form of contribution that is "actively harmful" to project health. I'm being intentionally divisive, but here's my argument. The "state of the art," "modern" "best practices" revolve around a PR (GitHub/GitLab/Gerrit/&c.) -style review process that enjoys an intentionally designed user experience and has many points of friction reduced or removed entirely.
When a patch arrives via Jira attachment, it passes through a process that suffers from a higher level of friction, something that actively discourages the level of code review that it could have received via PR. I believe that reduced friction results is a more thorough, thoughtful review and a review that's better able to handle large change-sets, vs. the attached patch process. Specific friction points include: * applying a patch for local evaluation is more tedious than checking out a PR branch. * each comment requires the reviewer to provide their own context (reference line numbers, copy-paste code snippets, &c) before saying anything at all. * threaded discussion around individual comments is impossibly difficult to manage for both participants and casual observers. * a super-human level of attention to detail is required on the parts of both contributor and reviewer to ensure that all review comments have been addressed. * syntax highlighting (while rudimentary vs. IDE-based evaluation) makes patches easier to read and digest. I claim "actively harmful" compared to the alternative because the above minor friction points, taken together, discourages the higher quality reviews that are possible by way of (1) the git-based interface to the contributed content and (2) a commenting system that supports contextual, threaded, and resolvable comments. The primary counter argument I've come up with is based around user access. It's possible that there's a contributor who has an Apache JIRA ID but not a GitHub ID, who is unwilling to make an account on the non-Apache service. Not accepting issue-attached patches means we exclude that contributor from our community. However, I suspect that the number of active and potential contributors who falls into that bucket is at or approaching zero. I suspect that the world of potential contributors who have a GitHub ID but refuse to make an Apache JIRA ID is actually far greater. Thus I propose we discontinue accepting patches attached to Jira issues; our contributor guide would exclusively ask for a PR; we can shut down the pre-commit robot from scanning Jira. Thanks in advance for your thoughtful participation in this discussion. Nick
