Hey Chris, Responses inline:
On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) < [email protected]> wrote: > Hi Team, > > I looked at: > > https://mail-archives.apache.org/mod_mbox/incubator-kudu-dev > > And over the last 4 months and Kudu’s inception, we have had > well over 2k+ emails, and looking back I found 4 actual threads > during that time (and one of which was a release VOTE thread) > that wasn’t automatically generated by Gerrit. > > Mar 2016 438 > Feb 2016 1003 > Jan 2016 1143 > Dec 2015 12 > Hmm, I did a search in my inbox for: [email protected] -gerrit -jira -"git commit" -dev-help -"svn commit" -moderate -"git push summary" and counted 30-35 threads. You're right, of course, that JIRA and gerrit eclipse the amount of email discussion, though. > > > If we are going to become an ASF top level project, the project > discussion has to happen on the mailing list. We had similar > issues in Spark and I realize that lots of project work is assisted > by tools and other technologies, but at the ASF, “if it didn’t > happen on the mailing list, it didn’t happen.” More-over it’s hard > to parse signal from noise in all these automated messages. Frankly > I don’t really know if anything good is going on - I know things > are going on, and I assume they are good, but it’s extremely hard > to verify that. > I think it's worth noting that the "automated' messages are typically code review requests and responses, which are developer discussion. Our project's culture is usually to use JIRAs and/or 'work-in-progress' patches in gerrit to communicate when we find a bug or want an opinion on something. For example, today I found a new bug https://issues.apache.org/jira/browse/KUDU-1369 and wrote up a quick work-in-progress for a a proposed solution and put it up at http://gerrit.cloudera.org:8080/#/c/2514/ . I think it would be redundant to also send an email to the list saying "Hey guys, I found a bug, here's a description". The same goes for design discussion -- eg http://gerrit.cloudera.org:8080/#/c/2443/ is a recent gerrit post that Dan made for a new feature he's working on. In this case he also sent an email to the dev list to point out the gerrit in case anyone missed it. I imagine a lot of people would filter the gerrit emails out of their inbox but not direct emails to the list (gerrit provides both headers and a subject line tag to make it easy to do) In terms of daily dev discussion, most of it has been happening on our Slack -- eg earlier today three contributors were discussing in-progress efforts on Spark RDD integration and sharing code via that channel. Most of the community members we've seen so far have tended to prefer this quick back-and-forth for discussion. Of course any _decisions_ will be made on the mailing list. If you think it would be useful to send a daily slack log to the mailing list, we can do that as well. > > I have a possible suggestions: > > * Create a [email protected] and send all automated > traffic there. *-issues is one option; we could make another name for > it. > Sure, we could do that. But, isn't it just as easy for people to set up a filter for 'kudu-CR' if they want to move those messages elsewhere? Our initial motivation when setting up mailing lists was to avoid having too many (makes it a pain for people to subscribe to them all). > > That will help to separate the signal from the noise in terms of > dev/architectural/etc. discussions from code reviews and automated > commit messages. > > One thing you may say is that dev/architectural discussions are happening > but they are in Gerrit. I would then say it’s extremely difficult to > separate the signal from the noise here, and as such, could be contributing > towards making it difficult for others to join the project, something > that we identified as an issue in our Incubator report. > Right. One option is that, for patches with bigger discussion, we can add a gerrit "reviewer" which is actually the dev mailing list. This would cause the discussion to be CCed there, and bring it to the attention of more people. Another thought is to do as you suggest above and move gerrit elsewhere, and just have a policy that whenever any gerrit starts getting architectural, that we send a ping to the dev mailing list to point it out (as Dan did with his recent design doc). -Todd
