Oops. See the email I just sent: "GitHub, Git, and contributor workflows"
Also, interested to her what Humbedooh thinks about this. CCed him. On 23 January 2014 16:31, Benjamin Young <[email protected]> wrote: > I had the good fortune of being in the #couchdb-meeting channel yesterday > when the meeting kicked off, and subsequently got tasked with proposing a > review process based on Github Pull Requests based on the recent "we need > more reviews" thread. > > To that end, here's the proposal for mixing Github Pull Requests (Github PRs > heretofore) into the Jira, Git, Mailing List mix. > > First, Github PRs are already in use by non-committer contributors (like > myself) and frequently used by the Fauxton devs (Garren & Sue mostly) for > reviewing each others more "volatile" patches. > > Second, this "process" can be added along side how things are done now, used > as found useful, and (in time) potentially become part of the daily process > of getting code into master. This proposal is to encourage the use of Github > PRs for anything non-trivial to get at least two sets of eyes on all the > code that hits master. Unlike a tool like Gerritt (which I've used in the > past), this is not a blocking process and can sit alongside (as it does now) > the current "a patchy" process of committing straight to master. > > The key thing missing from Github PRs is communication with the other tools > already in use: Jira and the Mailing Lists. > > I've done some research to bridge that gap, and come up with the following > options. > > Option 1: > Adding an @apache.org "bot" email address and Github account with > notification levels and "watch" status to relay PR comments to the Mailing > List. There is an Email Service Hook for Github repos, but it's limited to > commit activity (from what I could tell). Having a full account that handles > this can increase control on what's received, set a proper sender on the > emails to the list, etc. > https://help.github.com/articles/notifications > > Option 2 (likely too bothersome): > Github does offer a Jira service hook. It seems to only handle commit > activity and require specific commit message content to actually function: > https://github.com/github/github-services/blob/master/docs/jira > > Option 3 (much more overhead): > Zapier.com (would require $$ or a donation from them of an account to Apache > as well as "buy in" by Apache Infra, etc) can relay activity within a Github > project to many other tools including Email and Jira. The advantage with > this approach would be turning PRs and subsequent comments into Jira ticket > comments. The setup overhead is much greater, the ongoing expense > (possibly), and someone(s) to keep it fed/happy/working properly may obviate > it's value and use. > > > Option 1 is by far the more doable, easier to ship sooner and would get an > existing "process" in place with the existing tools. The same process done > for the Mailing List notifications could potentially be done (with a bit > more setup work) to get notifications sent to Jira. > > Objectives met by Option 1: > - add code review to Apache CouchDB process > - keep it an "additive" process (rather than a blocking one) > - increase cross-tool communication > > Hope that helps! :) > > Thanks, > Benjamin -- Noah Slater https://twitter.com/nslater
