It is my impression as mainly a lurker on a bunch of GH based projects, that there are a ton of younger software developers have no idea that other options besides Github even exist. We can tell them to open a JIRA, god forbid attach a patch to JIRA, but they'll shrug and forget about it. They might not even have any idea what we are talking about. Generating a patch file and handling it manually would be a (possibly unwelcome) revelation. So I think if we want to take these kinds of contributions the onus on doing everything other than interacting on the PR will be on the project committers. I think ultimately every ASF project is going to have to implement a pipeline for Github contributions, catering to the expectations and limitations of contributors who have only interacted with open source contribution via that platform, or otherwise we accept we've lost a whole generation of contributors.
On Tue, Aug 21, 2018 at 9:31 AM Sean Busbey <bus...@apache.org> wrote: > 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. > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
