Creating more actual (non-code-auto-emails) discussion on the M/L

["Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>]

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


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 have a possible suggestions:

* Create a issues@kudu.incubator.apache.org and send all automated
traffic there. *-issues is one option; we could make another name for
it. 

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.

Thoughts?

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Mike Percy <mp...@apache.org>]

On Thu, Mar 10, 2016 at 5:00 AM, Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov> wrote:
>
> - Even considering 40 threads I doubt there have only be <= 40 *decisions*
> on the project to date. IOW they are being made somewhere but it's unclear
> where. Email is easy to follow on a phone on the go whatever.
>

The Hadoop project has a tradition of design docs being posted to JIRA as
PDF, and discussion happening there. For example:
https://issues.apache.org/jira/browse/HDFS-7285 That approach seems OK, but
inferior to something that can be commented on inline (such as a text
document in a code review tool).

In Kudu, we've been trending toward decisions being made through
discussions on design docs happening in change requests like this one:
http://gerrit.cloudera.org/2443/ which seems like a reasonable way to
review a design doc. Once it's committed, the design doc lives in the main
ASF code repository, like these:
http://github.com/apache/incubator-kudu/tree/master/docs/design-docs (we're
also working on moving more design docs over from individual directories,
and legacy design docs that lived on Google Docs, into the central location
[1, 2]). I suppose another way to review designs would be to paste each doc
into an email on the list, and people could comment inline on it. Once
reviewed, I'd want us to commit it anyway, though. There are pros and cons
to this approach, relative to what we're doing now: One pro is that it
could be more transparent to people not intimately involved with the
project, especially to people browsing the dev list. On the downside, it
would be easier for the author to miss some comments while revising the
doc, be a bit messier, and people may still leave comments on Gerrit when
the author goes to do the final commit of the completed design doc. That
said, I personally wouldn't have a problem with trying it out.

* Create a issues@kudu.incubator.apache.org and send all automated
> traffic there. *-issues is one option; we could make another name for
> it.
>
> That will help to separate the signal from the noise in terms of
> dev/architectural/etc. discussions from code reviews and automated
> commit messages.
>

As of a couple weeks ago, we no longer sending JIRA traffic to dev@. It now
goes to issues@:
http://mail-archives.apache.org/mod_mbox/incubator-kudu-issues/

We might want to consider creating a reviews@ list to get the Gerrit
traffic off of the main dev list, if people want to use the archives to
browse non-tool oriented developer discussion on the dev list instead of
using email filters to separate out the different kinds of traffic. (I
personally use email fliters for that.)

Mike

[1] http://gerrit.cloudera.org/2499/
[2] http://gerrit.cloudera.org/2495/

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Todd Lipcon <to...@cloudera.com>]

On Thu, Mar 10, 2016 at 5:30 PM, Adar Dembo <ad...@cloudera.com> wrote:

> I wouldn't be opposed to moving gerrit traffic to another mailing list,
> though I'd prefer it be reviews@ instead of reusing issues@ because I
> think
> that's more predictable and organized. I also think adding a guide to using
> gerrit effectively for Kudu (linking back to the main gerrit guide) is
> definitely not a bad thing.
>
> As for hiding certain gerrit notifications, I'm less sure about that. I
> support the idea, but I also like the workflow of "upload a WIP patch (say,
> without new tests), later upload a patch with unit tests and remove WIP
> from the subject". I rely on the second e-mail to notify me that the patch
> is now ready to be reviewed, and I think your proposed change would prevent
> it from being generated, right?
>

I think so... though we could probably patch Gerrit to add a feature that
sends a notification if the subject line changes.


>
> On Thu, Mar 10, 2016 at 5:19 PM, David Alves <da...@gmail.com>
> wrote:
>
> > +1 to all of the above.
> >
> > -david
> >
> > On Thu, Mar 10, 2016 at 5:17 PM, Todd Lipcon <to...@cloudera.com> wrote:
> >
> > > One more action item: I think a lot of the "useless" traffic from
> gerrit
> > to
> > > the list is people uploading a new revision of an existing patch. It
> > looks
> > > like I can disable this and only have it post new reviews and comments,
> > and
> > > not bother posting "submitted" or "new revision".
> > >
> > > Of course if you're a listed reviewer (i.e have reviewed a previous
> > > revision) you'll still get notices when someone updates the review or
> > > submits it.
> > >
> > > Are people cool with this?
> > >
> > > -Todd
> > >
> > > On Thu, Mar 10, 2016 at 5:04 PM, Todd Lipcon <to...@cloudera.com>
> wrote:
> > >
> > > > Thanks, JD, Mike, and Adar for jumping in with more perspectives.
> > > >
> > > > I'm afraid that this thread might take a turn towards an unproductive
> > > > argument of "tooling vs mailing lists", but I don't think that was
> > > Chris's
> > > > main point. Neither do I think Chris is just trying to stir up
> trouble
> > > -- I
> > > > approached him about being a mentor for our incubation because I've
> > > always
> > > > found his advice to be unbiased, measured, and helpful towards
> > building a
> > > > good community.
> > > >
> > > > To try to drive this to a useful conclusion, let me propose a few
> > action
> > > > items:
> > > >
> > > > 1) Let's move gerrit traffic to a different list as discussed. I
> think
> > > > many of us already did filters like this for our own inboxes, but the
> > > point
> > > > about the archives being hard to read is a good one. I have a slight
> > > > preference to reuse the issues@ list instead of a new reviews@, both
> > to
> > > > keep the number of lists down, and because we often discuss and fix
> > bugs
> > > > more on gerrit than through lots of JIRA commentary. Makes sense that
> > the
> > > > filing of a bug, and its discussion/fix, would show up on the same
> > list.
> > > If
> > > > others disagree, though, I think reviews@ would be fine as well.
> > > >
> > > > 2) Chris also makes a good point that it's hard to extract signal
> from
> > > > noise in the flood of gerrit traffic. Slowing down development isn't
> a
> > > > great option, but I think we can use gerrit to our advantage here. It
> > > > actually allows users the ability to selectively watch certain paths
> in
> > > the
> > > > repository, which would be very helpful for new contributors who
> might
> > > for
> > > > example care a lot about changes to python/* but not to our consensus
> > > > implementation. Others might care a lot about design-docs/* for more
> > > > architectural discussions. I'll volunteer to write up a new section
> in
> > > our
> > > > 'contributing' guide that shows people how to selectively subscribe
> to
> > > the
> > > > areas of code they're interested in.
> > > >
> > > > Chris -- do the above items seem like positive changes from your
> > > > perspective? Are there any other concrete action items you think we
> > > should
> > > > consider?
> > > >
> > > > -Todd
> > > >
> > > >
> > > >
> > > > On Thu, Mar 10, 2016 at 4:39 PM, Adar Dembo <ad...@cloudera.com>
> wrote:
> > > >
> > > >> Hi Chris,
> > > >>
> > > >> I'm a new Apache committer and new to ASF in general. I have some
> > > >> experience with other open source projects, and as a developer I
> value
> > > the
> > > >> "advanced" tooling that many have adopted. If we assume
> > > >> everything-is-over-email as the baseline, this tooling includes:
> > > >> - Chat rooms for real-time communication, be it via IRC, Slack,
> > HipChat,
> > > >> etc.
> > > >> - Code review tools a la Review Board.
> > > >> - Complete workflow management tools a la GitHub, gerrit, etc.
> > > >> - Bug report trackers a la Bugzilla, JIRA, etc.
> > > >> Many of these tools are offered by Apache, so it seems like Apache's
> > > trend
> > > >> is towards "the right tool for the right job" rather than
> "everything
> > > must
> > > >> be communicated over e-mail".
> > > >>
> > > >> In particular, as someone who does a high volume of code review on
> > Kudu
> > > >> and
> > > >> other projects, I'll strongly value advances in review tooling.
> Taken
> > > >> together, they can save me hours of time in a given week. As for
> > design
> > > >> review, Dan and I discussed this at length when we transitioned from
> > > >> Google
> > > >> Docs to gerrit. You can see our back-and-forth here:
> > > >> http://gerrit.cloudera.org:8080/#/c/2149. Generally speaking I find
> > the
> > > >> "centralized commenting" approach of a system like Google Docs or
> > gerrit
> > > >> to
> > > >> be more useful than an e-mail thread, especially when one wants to
> > look
> > > >> back at a design discussion that took place in the past.
> > > >>
> > > >> Generally speaking, I suspect that moving more of Kudu's development
> > on
> > > >> mailing lists optimizes for the casual developer who rarely
> > contributes
> > > >> patches but wishes to "stay involved" in numerous Apache projects. I
> > > don't
> > > >> think we should be optimizing for this person; I'd prefer we
> optimize
> > > for
> > > >> folks who have deliberately decided to invest their time in Kudu,
> > > because
> > > >> they're thinking of using it to solve a problem, because they're
> > already
> > > >> using it, or because they find the technology to be just plain
> > > >> interesting.
> > > >> These developers will adapt themselves to whatever workflow the
> > project
> > > >> uses, are likely to produce large contributions, and are more likely
> > to
> > > >> appreciate some of the more advanced tooling that Kudu uses.
> > > >>
> > > >> Personally, I don't like being asked to slow down my workflow purely
> > on
> > > >> the
> > > >> faith that it will spur OSS adoption. What I see is someone who is
> not
> > > >> involved in Kudu's day-to-day activities requesting we make changes
> > > that,
> > > >> I
> > > >> think we both agree (in your words, "Email is slow and deliberate
> and
> > > not
> > > >> as fast or slick as gerrit etc, but that's a good thing"), will slow
> > > down
> > > >> Kudu development. Further, I see a blanket dismissal of Todd's (very
> > > >> reasonable) counterpoints. So I'm naturally being defensive; can you
> > > >> provide more substantive arguments as to why we should move
> > development
> > > >> discussions off of tools like gerrit and onto the dev mailing list?
> > > >>
> > > >>
> > > >> On Wed, Mar 9, 2016 at 7:00 PM, Mattmann, Chris A (3980) <
> > > >> chris.a.mattmann@jpl.nasa.gov> wrote:
> > > >>
> > > >> > Thanks for the reply Todd. Unfortunately it's more systematic than
> > > that.
> > > >> > Apologies for top post but am on my phone. Couple points:
> > > >> >
> > > >> > - interested to hear from others besides you on this. No offense
> > but I
> > > >> > think it's important that project members send email here to
> reply.
> > > >> >
> > > >> > - I hand counted the 4 threads of interest. Didn't run a fancy
> > command
> > > >> but
> > > >> > to be honest it's more indicative of the broader issue. Things
> > aren't
> > > >> > always solved through fancy greps and tools like gerrit. This is
> > going
> > > >> to
> > > >> > be a core issue with Kudu's incubation - how is someone not
> sitting
> > > in a
> > > >> > cube working on the project who isn't on those tools like gerrit
> and
> > > >> slack
> > > >> > which don't exist at the ASF going to join on the project?
> > > >> >
> > > >> > - Even considering 40 threads I doubt there have only be <= 40
> > > >> *decisions*
> > > >> > on the project to date. IOW they are being made somewhere but it's
> > > >> unclear
> > > >> > where. Email is easy to follow on a phone on the go whatever.
> > > >> >
> > > >> > As a mentor I would not be comfortable with Kudu being a TLP at
> this
> > > >> point
> > > >> > bc frankly projects need to use their dev list for more than
> > automated
> > > >> > discussion and big reports. Simple as that and sending a
> transcript
> > of
> > > >> > where convo is happening elsewhere is not going to cut it
> > > unfortunately.
> > > >> >
> > > >> > Email is slow and deliberate and not as fast or slick as gerrit
> etc,
> > > but
> > > >> > that's a good thing. It allows people the time needed to read and
> > join
> > > >> an
> > > >> > OSS community. It's too hard to do that with Kudu right now.
> > > >> >
> > > >> > Cheers,
> > > >> > Chris
> > > >> >
> > > >> > Sent from my iPhone
> > > >> >
> > > >> > > On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org>
> wrote:
> > > >> > >
> > > >> > > Hey Chris,
> > > >> > >
> > > >> > > Responses inline:
> > > >> > >
> > > >> > > On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
> > > >> > > chris.a.mattmann@jpl.nasa.gov> 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:
> > dev@kudu.incubator.apache.org
> > > >> > -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 issues@kudu.incubator.apache.org 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
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Todd Lipcon
> > > > Software Engineer, Cloudera
> > > >
> > >
> > >
> > >
> > > --
> > > Todd Lipcon
> > > Software Engineer, Cloudera
> > >
> >
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Adar Dembo <ad...@cloudera.com>]

I wouldn't be opposed to moving gerrit traffic to another mailing list,
though I'd prefer it be reviews@ instead of reusing issues@ because I think
that's more predictable and organized. I also think adding a guide to using
gerrit effectively for Kudu (linking back to the main gerrit guide) is
definitely not a bad thing.

As for hiding certain gerrit notifications, I'm less sure about that. I
support the idea, but I also like the workflow of "upload a WIP patch (say,
without new tests), later upload a patch with unit tests and remove WIP
from the subject". I rely on the second e-mail to notify me that the patch
is now ready to be reviewed, and I think your proposed change would prevent
it from being generated, right?

On Thu, Mar 10, 2016 at 5:19 PM, David Alves <da...@gmail.com> wrote:

> +1 to all of the above.
>
> -david
>
> On Thu, Mar 10, 2016 at 5:17 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
> > One more action item: I think a lot of the "useless" traffic from gerrit
> to
> > the list is people uploading a new revision of an existing patch. It
> looks
> > like I can disable this and only have it post new reviews and comments,
> and
> > not bother posting "submitted" or "new revision".
> >
> > Of course if you're a listed reviewer (i.e have reviewed a previous
> > revision) you'll still get notices when someone updates the review or
> > submits it.
> >
> > Are people cool with this?
> >
> > -Todd
> >
> > On Thu, Mar 10, 2016 at 5:04 PM, Todd Lipcon <to...@cloudera.com> wrote:
> >
> > > Thanks, JD, Mike, and Adar for jumping in with more perspectives.
> > >
> > > I'm afraid that this thread might take a turn towards an unproductive
> > > argument of "tooling vs mailing lists", but I don't think that was
> > Chris's
> > > main point. Neither do I think Chris is just trying to stir up trouble
> > -- I
> > > approached him about being a mentor for our incubation because I've
> > always
> > > found his advice to be unbiased, measured, and helpful towards
> building a
> > > good community.
> > >
> > > To try to drive this to a useful conclusion, let me propose a few
> action
> > > items:
> > >
> > > 1) Let's move gerrit traffic to a different list as discussed. I think
> > > many of us already did filters like this for our own inboxes, but the
> > point
> > > about the archives being hard to read is a good one. I have a slight
> > > preference to reuse the issues@ list instead of a new reviews@, both
> to
> > > keep the number of lists down, and because we often discuss and fix
> bugs
> > > more on gerrit than through lots of JIRA commentary. Makes sense that
> the
> > > filing of a bug, and its discussion/fix, would show up on the same
> list.
> > If
> > > others disagree, though, I think reviews@ would be fine as well.
> > >
> > > 2) Chris also makes a good point that it's hard to extract signal from
> > > noise in the flood of gerrit traffic. Slowing down development isn't a
> > > great option, but I think we can use gerrit to our advantage here. It
> > > actually allows users the ability to selectively watch certain paths in
> > the
> > > repository, which would be very helpful for new contributors who might
> > for
> > > example care a lot about changes to python/* but not to our consensus
> > > implementation. Others might care a lot about design-docs/* for more
> > > architectural discussions. I'll volunteer to write up a new section in
> > our
> > > 'contributing' guide that shows people how to selectively subscribe to
> > the
> > > areas of code they're interested in.
> > >
> > > Chris -- do the above items seem like positive changes from your
> > > perspective? Are there any other concrete action items you think we
> > should
> > > consider?
> > >
> > > -Todd
> > >
> > >
> > >
> > > On Thu, Mar 10, 2016 at 4:39 PM, Adar Dembo <ad...@cloudera.com> wrote:
> > >
> > >> Hi Chris,
> > >>
> > >> I'm a new Apache committer and new to ASF in general. I have some
> > >> experience with other open source projects, and as a developer I value
> > the
> > >> "advanced" tooling that many have adopted. If we assume
> > >> everything-is-over-email as the baseline, this tooling includes:
> > >> - Chat rooms for real-time communication, be it via IRC, Slack,
> HipChat,
> > >> etc.
> > >> - Code review tools a la Review Board.
> > >> - Complete workflow management tools a la GitHub, gerrit, etc.
> > >> - Bug report trackers a la Bugzilla, JIRA, etc.
> > >> Many of these tools are offered by Apache, so it seems like Apache's
> > trend
> > >> is towards "the right tool for the right job" rather than "everything
> > must
> > >> be communicated over e-mail".
> > >>
> > >> In particular, as someone who does a high volume of code review on
> Kudu
> > >> and
> > >> other projects, I'll strongly value advances in review tooling. Taken
> > >> together, they can save me hours of time in a given week. As for
> design
> > >> review, Dan and I discussed this at length when we transitioned from
> > >> Google
> > >> Docs to gerrit. You can see our back-and-forth here:
> > >> http://gerrit.cloudera.org:8080/#/c/2149. Generally speaking I find
> the
> > >> "centralized commenting" approach of a system like Google Docs or
> gerrit
> > >> to
> > >> be more useful than an e-mail thread, especially when one wants to
> look
> > >> back at a design discussion that took place in the past.
> > >>
> > >> Generally speaking, I suspect that moving more of Kudu's development
> on
> > >> mailing lists optimizes for the casual developer who rarely
> contributes
> > >> patches but wishes to "stay involved" in numerous Apache projects. I
> > don't
> > >> think we should be optimizing for this person; I'd prefer we optimize
> > for
> > >> folks who have deliberately decided to invest their time in Kudu,
> > because
> > >> they're thinking of using it to solve a problem, because they're
> already
> > >> using it, or because they find the technology to be just plain
> > >> interesting.
> > >> These developers will adapt themselves to whatever workflow the
> project
> > >> uses, are likely to produce large contributions, and are more likely
> to
> > >> appreciate some of the more advanced tooling that Kudu uses.
> > >>
> > >> Personally, I don't like being asked to slow down my workflow purely
> on
> > >> the
> > >> faith that it will spur OSS adoption. What I see is someone who is not
> > >> involved in Kudu's day-to-day activities requesting we make changes
> > that,
> > >> I
> > >> think we both agree (in your words, "Email is slow and deliberate and
> > not
> > >> as fast or slick as gerrit etc, but that's a good thing"), will slow
> > down
> > >> Kudu development. Further, I see a blanket dismissal of Todd's (very
> > >> reasonable) counterpoints. So I'm naturally being defensive; can you
> > >> provide more substantive arguments as to why we should move
> development
> > >> discussions off of tools like gerrit and onto the dev mailing list?
> > >>
> > >>
> > >> On Wed, Mar 9, 2016 at 7:00 PM, Mattmann, Chris A (3980) <
> > >> chris.a.mattmann@jpl.nasa.gov> wrote:
> > >>
> > >> > Thanks for the reply Todd. Unfortunately it's more systematic than
> > that.
> > >> > Apologies for top post but am on my phone. Couple points:
> > >> >
> > >> > - interested to hear from others besides you on this. No offense
> but I
> > >> > think it's important that project members send email here to reply.
> > >> >
> > >> > - I hand counted the 4 threads of interest. Didn't run a fancy
> command
> > >> but
> > >> > to be honest it's more indicative of the broader issue. Things
> aren't
> > >> > always solved through fancy greps and tools like gerrit. This is
> going
> > >> to
> > >> > be a core issue with Kudu's incubation - how is someone not sitting
> > in a
> > >> > cube working on the project who isn't on those tools like gerrit and
> > >> slack
> > >> > which don't exist at the ASF going to join on the project?
> > >> >
> > >> > - Even considering 40 threads I doubt there have only be <= 40
> > >> *decisions*
> > >> > on the project to date. IOW they are being made somewhere but it's
> > >> unclear
> > >> > where. Email is easy to follow on a phone on the go whatever.
> > >> >
> > >> > As a mentor I would not be comfortable with Kudu being a TLP at this
> > >> point
> > >> > bc frankly projects need to use their dev list for more than
> automated
> > >> > discussion and big reports. Simple as that and sending a transcript
> of
> > >> > where convo is happening elsewhere is not going to cut it
> > unfortunately.
> > >> >
> > >> > Email is slow and deliberate and not as fast or slick as gerrit etc,
> > but
> > >> > that's a good thing. It allows people the time needed to read and
> join
> > >> an
> > >> > OSS community. It's too hard to do that with Kudu right now.
> > >> >
> > >> > Cheers,
> > >> > Chris
> > >> >
> > >> > Sent from my iPhone
> > >> >
> > >> > > On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
> > >> > >
> > >> > > Hey Chris,
> > >> > >
> > >> > > Responses inline:
> > >> > >
> > >> > > On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
> > >> > > chris.a.mattmann@jpl.nasa.gov> 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:
> dev@kudu.incubator.apache.org
> > >> > -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 issues@kudu.incubator.apache.org 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
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Todd Lipcon
> > > Software Engineer, Cloudera
> > >
> >
> >
> >
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
> >
>

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[David Alves <da...@gmail.com>]

+1 to all of the above.

-david

On Thu, Mar 10, 2016 at 5:17 PM, Todd Lipcon <to...@cloudera.com> wrote:

> One more action item: I think a lot of the "useless" traffic from gerrit to
> the list is people uploading a new revision of an existing patch. It looks
> like I can disable this and only have it post new reviews and comments, and
> not bother posting "submitted" or "new revision".
>
> Of course if you're a listed reviewer (i.e have reviewed a previous
> revision) you'll still get notices when someone updates the review or
> submits it.
>
> Are people cool with this?
>
> -Todd
>
> On Thu, Mar 10, 2016 at 5:04 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
> > Thanks, JD, Mike, and Adar for jumping in with more perspectives.
> >
> > I'm afraid that this thread might take a turn towards an unproductive
> > argument of "tooling vs mailing lists", but I don't think that was
> Chris's
> > main point. Neither do I think Chris is just trying to stir up trouble
> -- I
> > approached him about being a mentor for our incubation because I've
> always
> > found his advice to be unbiased, measured, and helpful towards building a
> > good community.
> >
> > To try to drive this to a useful conclusion, let me propose a few action
> > items:
> >
> > 1) Let's move gerrit traffic to a different list as discussed. I think
> > many of us already did filters like this for our own inboxes, but the
> point
> > about the archives being hard to read is a good one. I have a slight
> > preference to reuse the issues@ list instead of a new reviews@, both to
> > keep the number of lists down, and because we often discuss and fix bugs
> > more on gerrit than through lots of JIRA commentary. Makes sense that the
> > filing of a bug, and its discussion/fix, would show up on the same list.
> If
> > others disagree, though, I think reviews@ would be fine as well.
> >
> > 2) Chris also makes a good point that it's hard to extract signal from
> > noise in the flood of gerrit traffic. Slowing down development isn't a
> > great option, but I think we can use gerrit to our advantage here. It
> > actually allows users the ability to selectively watch certain paths in
> the
> > repository, which would be very helpful for new contributors who might
> for
> > example care a lot about changes to python/* but not to our consensus
> > implementation. Others might care a lot about design-docs/* for more
> > architectural discussions. I'll volunteer to write up a new section in
> our
> > 'contributing' guide that shows people how to selectively subscribe to
> the
> > areas of code they're interested in.
> >
> > Chris -- do the above items seem like positive changes from your
> > perspective? Are there any other concrete action items you think we
> should
> > consider?
> >
> > -Todd
> >
> >
> >
> > On Thu, Mar 10, 2016 at 4:39 PM, Adar Dembo <ad...@cloudera.com> wrote:
> >
> >> Hi Chris,
> >>
> >> I'm a new Apache committer and new to ASF in general. I have some
> >> experience with other open source projects, and as a developer I value
> the
> >> "advanced" tooling that many have adopted. If we assume
> >> everything-is-over-email as the baseline, this tooling includes:
> >> - Chat rooms for real-time communication, be it via IRC, Slack, HipChat,
> >> etc.
> >> - Code review tools a la Review Board.
> >> - Complete workflow management tools a la GitHub, gerrit, etc.
> >> - Bug report trackers a la Bugzilla, JIRA, etc.
> >> Many of these tools are offered by Apache, so it seems like Apache's
> trend
> >> is towards "the right tool for the right job" rather than "everything
> must
> >> be communicated over e-mail".
> >>
> >> In particular, as someone who does a high volume of code review on Kudu
> >> and
> >> other projects, I'll strongly value advances in review tooling. Taken
> >> together, they can save me hours of time in a given week. As for design
> >> review, Dan and I discussed this at length when we transitioned from
> >> Google
> >> Docs to gerrit. You can see our back-and-forth here:
> >> http://gerrit.cloudera.org:8080/#/c/2149. Generally speaking I find the
> >> "centralized commenting" approach of a system like Google Docs or gerrit
> >> to
> >> be more useful than an e-mail thread, especially when one wants to look
> >> back at a design discussion that took place in the past.
> >>
> >> Generally speaking, I suspect that moving more of Kudu's development on
> >> mailing lists optimizes for the casual developer who rarely contributes
> >> patches but wishes to "stay involved" in numerous Apache projects. I
> don't
> >> think we should be optimizing for this person; I'd prefer we optimize
> for
> >> folks who have deliberately decided to invest their time in Kudu,
> because
> >> they're thinking of using it to solve a problem, because they're already
> >> using it, or because they find the technology to be just plain
> >> interesting.
> >> These developers will adapt themselves to whatever workflow the project
> >> uses, are likely to produce large contributions, and are more likely to
> >> appreciate some of the more advanced tooling that Kudu uses.
> >>
> >> Personally, I don't like being asked to slow down my workflow purely on
> >> the
> >> faith that it will spur OSS adoption. What I see is someone who is not
> >> involved in Kudu's day-to-day activities requesting we make changes
> that,
> >> I
> >> think we both agree (in your words, "Email is slow and deliberate and
> not
> >> as fast or slick as gerrit etc, but that's a good thing"), will slow
> down
> >> Kudu development. Further, I see a blanket dismissal of Todd's (very
> >> reasonable) counterpoints. So I'm naturally being defensive; can you
> >> provide more substantive arguments as to why we should move development
> >> discussions off of tools like gerrit and onto the dev mailing list?
> >>
> >>
> >> On Wed, Mar 9, 2016 at 7:00 PM, Mattmann, Chris A (3980) <
> >> chris.a.mattmann@jpl.nasa.gov> wrote:
> >>
> >> > Thanks for the reply Todd. Unfortunately it's more systematic than
> that.
> >> > Apologies for top post but am on my phone. Couple points:
> >> >
> >> > - interested to hear from others besides you on this. No offense but I
> >> > think it's important that project members send email here to reply.
> >> >
> >> > - I hand counted the 4 threads of interest. Didn't run a fancy command
> >> but
> >> > to be honest it's more indicative of the broader issue. Things aren't
> >> > always solved through fancy greps and tools like gerrit. This is going
> >> to
> >> > be a core issue with Kudu's incubation - how is someone not sitting
> in a
> >> > cube working on the project who isn't on those tools like gerrit and
> >> slack
> >> > which don't exist at the ASF going to join on the project?
> >> >
> >> > - Even considering 40 threads I doubt there have only be <= 40
> >> *decisions*
> >> > on the project to date. IOW they are being made somewhere but it's
> >> unclear
> >> > where. Email is easy to follow on a phone on the go whatever.
> >> >
> >> > As a mentor I would not be comfortable with Kudu being a TLP at this
> >> point
> >> > bc frankly projects need to use their dev list for more than automated
> >> > discussion and big reports. Simple as that and sending a transcript of
> >> > where convo is happening elsewhere is not going to cut it
> unfortunately.
> >> >
> >> > Email is slow and deliberate and not as fast or slick as gerrit etc,
> but
> >> > that's a good thing. It allows people the time needed to read and join
> >> an
> >> > OSS community. It's too hard to do that with Kudu right now.
> >> >
> >> > Cheers,
> >> > Chris
> >> >
> >> > Sent from my iPhone
> >> >
> >> > > On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
> >> > >
> >> > > Hey Chris,
> >> > >
> >> > > Responses inline:
> >> > >
> >> > > On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
> >> > > chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org
> >> > -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 issues@kudu.incubator.apache.org 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
> >> >
> >>
> >
> >
> >
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
> >
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Todd Lipcon <to...@cloudera.com>]

One more action item: I think a lot of the "useless" traffic from gerrit to
the list is people uploading a new revision of an existing patch. It looks
like I can disable this and only have it post new reviews and comments, and
not bother posting "submitted" or "new revision".

Of course if you're a listed reviewer (i.e have reviewed a previous
revision) you'll still get notices when someone updates the review or
submits it.

Are people cool with this?

-Todd

On Thu, Mar 10, 2016 at 5:04 PM, Todd Lipcon <to...@cloudera.com> wrote:

> Thanks, JD, Mike, and Adar for jumping in with more perspectives.
>
> I'm afraid that this thread might take a turn towards an unproductive
> argument of "tooling vs mailing lists", but I don't think that was Chris's
> main point. Neither do I think Chris is just trying to stir up trouble -- I
> approached him about being a mentor for our incubation because I've always
> found his advice to be unbiased, measured, and helpful towards building a
> good community.
>
> To try to drive this to a useful conclusion, let me propose a few action
> items:
>
> 1) Let's move gerrit traffic to a different list as discussed. I think
> many of us already did filters like this for our own inboxes, but the point
> about the archives being hard to read is a good one. I have a slight
> preference to reuse the issues@ list instead of a new reviews@, both to
> keep the number of lists down, and because we often discuss and fix bugs
> more on gerrit than through lots of JIRA commentary. Makes sense that the
> filing of a bug, and its discussion/fix, would show up on the same list. If
> others disagree, though, I think reviews@ would be fine as well.
>
> 2) Chris also makes a good point that it's hard to extract signal from
> noise in the flood of gerrit traffic. Slowing down development isn't a
> great option, but I think we can use gerrit to our advantage here. It
> actually allows users the ability to selectively watch certain paths in the
> repository, which would be very helpful for new contributors who might for
> example care a lot about changes to python/* but not to our consensus
> implementation. Others might care a lot about design-docs/* for more
> architectural discussions. I'll volunteer to write up a new section in our
> 'contributing' guide that shows people how to selectively subscribe to the
> areas of code they're interested in.
>
> Chris -- do the above items seem like positive changes from your
> perspective? Are there any other concrete action items you think we should
> consider?
>
> -Todd
>
>
>
> On Thu, Mar 10, 2016 at 4:39 PM, Adar Dembo <ad...@cloudera.com> wrote:
>
>> Hi Chris,
>>
>> I'm a new Apache committer and new to ASF in general. I have some
>> experience with other open source projects, and as a developer I value the
>> "advanced" tooling that many have adopted. If we assume
>> everything-is-over-email as the baseline, this tooling includes:
>> - Chat rooms for real-time communication, be it via IRC, Slack, HipChat,
>> etc.
>> - Code review tools a la Review Board.
>> - Complete workflow management tools a la GitHub, gerrit, etc.
>> - Bug report trackers a la Bugzilla, JIRA, etc.
>> Many of these tools are offered by Apache, so it seems like Apache's trend
>> is towards "the right tool for the right job" rather than "everything must
>> be communicated over e-mail".
>>
>> In particular, as someone who does a high volume of code review on Kudu
>> and
>> other projects, I'll strongly value advances in review tooling. Taken
>> together, they can save me hours of time in a given week. As for design
>> review, Dan and I discussed this at length when we transitioned from
>> Google
>> Docs to gerrit. You can see our back-and-forth here:
>> http://gerrit.cloudera.org:8080/#/c/2149. Generally speaking I find the
>> "centralized commenting" approach of a system like Google Docs or gerrit
>> to
>> be more useful than an e-mail thread, especially when one wants to look
>> back at a design discussion that took place in the past.
>>
>> Generally speaking, I suspect that moving more of Kudu's development on
>> mailing lists optimizes for the casual developer who rarely contributes
>> patches but wishes to "stay involved" in numerous Apache projects. I don't
>> think we should be optimizing for this person; I'd prefer we optimize for
>> folks who have deliberately decided to invest their time in Kudu, because
>> they're thinking of using it to solve a problem, because they're already
>> using it, or because they find the technology to be just plain
>> interesting.
>> These developers will adapt themselves to whatever workflow the project
>> uses, are likely to produce large contributions, and are more likely to
>> appreciate some of the more advanced tooling that Kudu uses.
>>
>> Personally, I don't like being asked to slow down my workflow purely on
>> the
>> faith that it will spur OSS adoption. What I see is someone who is not
>> involved in Kudu's day-to-day activities requesting we make changes that,
>> I
>> think we both agree (in your words, "Email is slow and deliberate and not
>> as fast or slick as gerrit etc, but that's a good thing"), will slow down
>> Kudu development. Further, I see a blanket dismissal of Todd's (very
>> reasonable) counterpoints. So I'm naturally being defensive; can you
>> provide more substantive arguments as to why we should move development
>> discussions off of tools like gerrit and onto the dev mailing list?
>>
>>
>> On Wed, Mar 9, 2016 at 7:00 PM, Mattmann, Chris A (3980) <
>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>
>> > Thanks for the reply Todd. Unfortunately it's more systematic than that.
>> > Apologies for top post but am on my phone. Couple points:
>> >
>> > - interested to hear from others besides you on this. No offense but I
>> > think it's important that project members send email here to reply.
>> >
>> > - I hand counted the 4 threads of interest. Didn't run a fancy command
>> but
>> > to be honest it's more indicative of the broader issue. Things aren't
>> > always solved through fancy greps and tools like gerrit. This is going
>> to
>> > be a core issue with Kudu's incubation - how is someone not sitting in a
>> > cube working on the project who isn't on those tools like gerrit and
>> slack
>> > which don't exist at the ASF going to join on the project?
>> >
>> > - Even considering 40 threads I doubt there have only be <= 40
>> *decisions*
>> > on the project to date. IOW they are being made somewhere but it's
>> unclear
>> > where. Email is easy to follow on a phone on the go whatever.
>> >
>> > As a mentor I would not be comfortable with Kudu being a TLP at this
>> point
>> > bc frankly projects need to use their dev list for more than automated
>> > discussion and big reports. Simple as that and sending a transcript of
>> > where convo is happening elsewhere is not going to cut it unfortunately.
>> >
>> > Email is slow and deliberate and not as fast or slick as gerrit etc, but
>> > that's a good thing. It allows people the time needed to read and join
>> an
>> > OSS community. It's too hard to do that with Kudu right now.
>> >
>> > Cheers,
>> > Chris
>> >
>> > Sent from my iPhone
>> >
>> > > On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
>> > >
>> > > Hey Chris,
>> > >
>> > > Responses inline:
>> > >
>> > > On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
>> > > chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org
>> > -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 issues@kudu.incubator.apache.org 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
>> >
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Todd Lipcon <to...@cloudera.com>]

Thanks, JD, Mike, and Adar for jumping in with more perspectives.

I'm afraid that this thread might take a turn towards an unproductive
argument of "tooling vs mailing lists", but I don't think that was Chris's
main point. Neither do I think Chris is just trying to stir up trouble -- I
approached him about being a mentor for our incubation because I've always
found his advice to be unbiased, measured, and helpful towards building a
good community.

To try to drive this to a useful conclusion, let me propose a few action
items:

1) Let's move gerrit traffic to a different list as discussed. I think many
of us already did filters like this for our own inboxes, but the point
about the archives being hard to read is a good one. I have a slight
preference to reuse the issues@ list instead of a new reviews@, both to
keep the number of lists down, and because we often discuss and fix bugs
more on gerrit than through lots of JIRA commentary. Makes sense that the
filing of a bug, and its discussion/fix, would show up on the same list. If
others disagree, though, I think reviews@ would be fine as well.

2) Chris also makes a good point that it's hard to extract signal from
noise in the flood of gerrit traffic. Slowing down development isn't a
great option, but I think we can use gerrit to our advantage here. It
actually allows users the ability to selectively watch certain paths in the
repository, which would be very helpful for new contributors who might for
example care a lot about changes to python/* but not to our consensus
implementation. Others might care a lot about design-docs/* for more
architectural discussions. I'll volunteer to write up a new section in our
'contributing' guide that shows people how to selectively subscribe to the
areas of code they're interested in.

Chris -- do the above items seem like positive changes from your
perspective? Are there any other concrete action items you think we should
consider?

-Todd



On Thu, Mar 10, 2016 at 4:39 PM, Adar Dembo <ad...@cloudera.com> wrote:

> Hi Chris,
>
> I'm a new Apache committer and new to ASF in general. I have some
> experience with other open source projects, and as a developer I value the
> "advanced" tooling that many have adopted. If we assume
> everything-is-over-email as the baseline, this tooling includes:
> - Chat rooms for real-time communication, be it via IRC, Slack, HipChat,
> etc.
> - Code review tools a la Review Board.
> - Complete workflow management tools a la GitHub, gerrit, etc.
> - Bug report trackers a la Bugzilla, JIRA, etc.
> Many of these tools are offered by Apache, so it seems like Apache's trend
> is towards "the right tool for the right job" rather than "everything must
> be communicated over e-mail".
>
> In particular, as someone who does a high volume of code review on Kudu and
> other projects, I'll strongly value advances in review tooling. Taken
> together, they can save me hours of time in a given week. As for design
> review, Dan and I discussed this at length when we transitioned from Google
> Docs to gerrit. You can see our back-and-forth here:
> http://gerrit.cloudera.org:8080/#/c/2149. Generally speaking I find the
> "centralized commenting" approach of a system like Google Docs or gerrit to
> be more useful than an e-mail thread, especially when one wants to look
> back at a design discussion that took place in the past.
>
> Generally speaking, I suspect that moving more of Kudu's development on
> mailing lists optimizes for the casual developer who rarely contributes
> patches but wishes to "stay involved" in numerous Apache projects. I don't
> think we should be optimizing for this person; I'd prefer we optimize for
> folks who have deliberately decided to invest their time in Kudu, because
> they're thinking of using it to solve a problem, because they're already
> using it, or because they find the technology to be just plain interesting.
> These developers will adapt themselves to whatever workflow the project
> uses, are likely to produce large contributions, and are more likely to
> appreciate some of the more advanced tooling that Kudu uses.
>
> Personally, I don't like being asked to slow down my workflow purely on the
> faith that it will spur OSS adoption. What I see is someone who is not
> involved in Kudu's day-to-day activities requesting we make changes that, I
> think we both agree (in your words, "Email is slow and deliberate and not
> as fast or slick as gerrit etc, but that's a good thing"), will slow down
> Kudu development. Further, I see a blanket dismissal of Todd's (very
> reasonable) counterpoints. So I'm naturally being defensive; can you
> provide more substantive arguments as to why we should move development
> discussions off of tools like gerrit and onto the dev mailing list?
>
>
> On Wed, Mar 9, 2016 at 7:00 PM, Mattmann, Chris A (3980) <
> chris.a.mattmann@jpl.nasa.gov> wrote:
>
> > Thanks for the reply Todd. Unfortunately it's more systematic than that.
> > Apologies for top post but am on my phone. Couple points:
> >
> > - interested to hear from others besides you on this. No offense but I
> > think it's important that project members send email here to reply.
> >
> > - I hand counted the 4 threads of interest. Didn't run a fancy command
> but
> > to be honest it's more indicative of the broader issue. Things aren't
> > always solved through fancy greps and tools like gerrit. This is going to
> > be a core issue with Kudu's incubation - how is someone not sitting in a
> > cube working on the project who isn't on those tools like gerrit and
> slack
> > which don't exist at the ASF going to join on the project?
> >
> > - Even considering 40 threads I doubt there have only be <= 40
> *decisions*
> > on the project to date. IOW they are being made somewhere but it's
> unclear
> > where. Email is easy to follow on a phone on the go whatever.
> >
> > As a mentor I would not be comfortable with Kudu being a TLP at this
> point
> > bc frankly projects need to use their dev list for more than automated
> > discussion and big reports. Simple as that and sending a transcript of
> > where convo is happening elsewhere is not going to cut it unfortunately.
> >
> > Email is slow and deliberate and not as fast or slick as gerrit etc, but
> > that's a good thing. It allows people the time needed to read and join an
> > OSS community. It's too hard to do that with Kudu right now.
> >
> > Cheers,
> > Chris
> >
> > Sent from my iPhone
> >
> > > On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
> > >
> > > Hey Chris,
> > >
> > > Responses inline:
> > >
> > > On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
> > > chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org
> > -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 issues@kudu.incubator.apache.org 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
> >
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Adar Dembo <ad...@cloudera.com>]

Hi Chris,

I'm a new Apache committer and new to ASF in general. I have some
experience with other open source projects, and as a developer I value the
"advanced" tooling that many have adopted. If we assume
everything-is-over-email as the baseline, this tooling includes:
- Chat rooms for real-time communication, be it via IRC, Slack, HipChat,
etc.
- Code review tools a la Review Board.
- Complete workflow management tools a la GitHub, gerrit, etc.
- Bug report trackers a la Bugzilla, JIRA, etc.
Many of these tools are offered by Apache, so it seems like Apache's trend
is towards "the right tool for the right job" rather than "everything must
be communicated over e-mail".

In particular, as someone who does a high volume of code review on Kudu and
other projects, I'll strongly value advances in review tooling. Taken
together, they can save me hours of time in a given week. As for design
review, Dan and I discussed this at length when we transitioned from Google
Docs to gerrit. You can see our back-and-forth here:
http://gerrit.cloudera.org:8080/#/c/2149. Generally speaking I find the
"centralized commenting" approach of a system like Google Docs or gerrit to
be more useful than an e-mail thread, especially when one wants to look
back at a design discussion that took place in the past.

Generally speaking, I suspect that moving more of Kudu's development on
mailing lists optimizes for the casual developer who rarely contributes
patches but wishes to "stay involved" in numerous Apache projects. I don't
think we should be optimizing for this person; I'd prefer we optimize for
folks who have deliberately decided to invest their time in Kudu, because
they're thinking of using it to solve a problem, because they're already
using it, or because they find the technology to be just plain interesting.
These developers will adapt themselves to whatever workflow the project
uses, are likely to produce large contributions, and are more likely to
appreciate some of the more advanced tooling that Kudu uses.

Personally, I don't like being asked to slow down my workflow purely on the
faith that it will spur OSS adoption. What I see is someone who is not
involved in Kudu's day-to-day activities requesting we make changes that, I
think we both agree (in your words, "Email is slow and deliberate and not
as fast or slick as gerrit etc, but that's a good thing"), will slow down
Kudu development. Further, I see a blanket dismissal of Todd's (very
reasonable) counterpoints. So I'm naturally being defensive; can you
provide more substantive arguments as to why we should move development
discussions off of tools like gerrit and onto the dev mailing list?


On Wed, Mar 9, 2016 at 7:00 PM, Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov> wrote:

> Thanks for the reply Todd. Unfortunately it's more systematic than that.
> Apologies for top post but am on my phone. Couple points:
>
> - interested to hear from others besides you on this. No offense but I
> think it's important that project members send email here to reply.
>
> - I hand counted the 4 threads of interest. Didn't run a fancy command but
> to be honest it's more indicative of the broader issue. Things aren't
> always solved through fancy greps and tools like gerrit. This is going to
> be a core issue with Kudu's incubation - how is someone not sitting in a
> cube working on the project who isn't on those tools like gerrit and slack
> which don't exist at the ASF going to join on the project?
>
> - Even considering 40 threads I doubt there have only be <= 40 *decisions*
> on the project to date. IOW they are being made somewhere but it's unclear
> where. Email is easy to follow on a phone on the go whatever.
>
> As a mentor I would not be comfortable with Kudu being a TLP at this point
> bc frankly projects need to use their dev list for more than automated
> discussion and big reports. Simple as that and sending a transcript of
> where convo is happening elsewhere is not going to cut it unfortunately.
>
> Email is slow and deliberate and not as fast or slick as gerrit etc, but
> that's a good thing. It allows people the time needed to read and join an
> OSS community. It's too hard to do that with Kudu right now.
>
> Cheers,
> Chris
>
> Sent from my iPhone
>
> > On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
> >
> > Hey Chris,
> >
> > Responses inline:
> >
> > On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
> > chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org
> -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 issues@kudu.incubator.apache.org 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
>

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Mike Percy <mp...@apache.org>]

On Tue, Mar 15, 2016 at 4:04 AM, Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov> wrote:

> Good comments about Hadoop and comparisons there. The thing is all
> projects are different in some sense, so comments to me like “Project
> X did it this way, so Y” may not mean that Kudu must do it that way.
>

Yeah, totally agree. Seems like we should aim for what's best for the dual
goals of growing the community and enabling effective and efficient
workflows.

When I talk about design, I am not necessarily talking about design
> docs, but talking about the regular conversation and though process
> / roadmap indicating where things are going on. For me, that’s
> missing in Kudu


Gotcha. Thanks for the perspective. We could post a roadmap to the web site
with links to major work items (JIRAs, etc). That could help with
discoverability of ongoing dev efforts. The last Kudu roadmap I saw was
proposed by JD on the list [1] but it's not published elsewhere AFAIK. Just
hopefully we can help users take a published roadmap with a grain of
salt... I've seen people in other projects get irritated because their
favorite feature that was on the roadmap didn't get implemented on the
proposed project schedule (well, this is software after all, and
open-source software at that).

as a casual reader of the dev list, my *main* entry point into ASF projects
> (and really
> as someone who’s been around the ASF since 2004, what I really
> consider the life-blood of the project), I would have and do not
> have a clue as to what is going on.


>From my point of view, the high-level vision of "where we're going" as a
software project is ideally embodied in a (living) roadmap, while the
tactical plan of "how we're going to get there" is embodied in the design
docs (and comments about them) and patches (with associated code review
comments). On the tactical side, soliciting design feedback on the mailing
list (as mentioned previously, like Dan [2] and Adar [3] have recently
done) as well as reducing the number of tool mails to the list sounds like
a boon to visibility and discoverability. OTOH, I don't think every minor
patch needs a dev@ thread -- that's what reviews@ should be for.

Mike

[1]
http://mail-archives.apache.org/mod_mbox/kudu-dev/201602.mbox/%3CCAGpTDNcMBWwX8p+yGKzHfL2xcmKTScU-rhLcQFSns1UVSbrXhw@mail.gmail.com%3E
[2]
http://mail-archives.apache.org/mod_mbox/kudu-dev/201603.mbox/%3CCALo2W-UQOPBMmTq2ceRzZFtBk6756wiZSrwtQNPAw%3D-EzDpiRA%40mail.gmail.com%3E
[3]
http://mail-archives.apache.org/mod_mbox/kudu-dev/201603.mbox/%3CCAMcOB6NBcaBnigpQPBD5NrZrieB4qjv1uG0T6QZy-VTL6Ad4eQ%40mail.gmail.com%3E

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

["Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>]

Hi Everyone,

Thanks for the replies. Todd, I think that your 2 suggested updates,
moving the traffic of gerrit to *-issues@k.i.a.o sounds good to me,
and also the subscription email technique could also help more.
Also my only other advice is periodically to send thoughts to
dev@k.i.a.o to give people a roadmap of things that matter to each
of you and what you would want others outside of your circle to
know about if they were to want to jump in. Sometimes as I mention
below this is an email to the dev list (“Here’s what’s interesting
to me, you may want to check out <these links> where <these links>
could be Gerrit, JIRA, mailing list pointer, etc etc.”) This goes
a long way towards welcoming us slow pokes to your minds and dev
cycles and seeing where we can help.

I have also taken the time to reply individually to those emails
that were sent. Somehow (mea culpa) I didn’t see the replies. Sigh.
Cue laugh track.

Replies to: Mike Percy

Good comments about Hadoop and comparisons there. The thing is all
projects are different in some sense, so comments to me like “Project
X did it this way, so Y” may not mean that Kudu must do it that way.

When I talk about design, I am not necessarily talking about design
docs, but talking about the regular conversation and though process
/ roadmap indicating where things are going on. For me, that’s
missing in Kudu - I’ve had several IM discussions with Todd about
this, and he is able to give me a great roadmap of issue X is here
at JIRA, and then cross referenced at Gerrit, and then it’s related
to some code push in Git here, etc. etc. However as a casual reader
of the dev list, my *main* entry point into ASF projects (and really
as someone who’s been around the ASF since 2004, what I really
consider the life-blood of the project), I would have and do not
have a clue as to what is going on. I see daily heavy streams of
Gerrit emails, and so forth on the dev list, but I do not see people
talking to one another, saying things like:

==ExA:

Hey KUDU-YYY is an important issue! I just merged it, check out the
latest Git master and everyone give it a look-see.

==ExB:

Hey Todd, you are in California and I’m in China - I have a design
idea I wanted you to look at so I created this Y Gerrit review here,
this JIRA issue Z here, and then this wiki page A here. Please have
a look and give me feedback.

Things like the above help people like me say, “oh, I want to be a
part of that! Todd’s working on it; or Person B!” and then I’ll go
have a look. Moreover, it also helps me help maintain shared community
and ownership of the decisions and thoughts related to the code
which should be shared by the community. It’s hard to follow when
there is a small core of rapidly moving individuals who know what
they want to do, and are all working at the same pace. I’m not paid
to work on Kudu and so it’s hard for me to do that pace.

Replies to Jean-Daniel Cryans:

No it’s not the 90’s I just am not in that big open room you’re
talking about. I’m in a room with bits and bytes whizzing by, linking
to systems like Gerrit, and Slack convos, and other things which
frankly I don’t have enough open tabs in my browser to keep track
of and which don’t display nicely on my iPhone 6s mail app (which
was built long after the 90s).

In general though it seems like you got my point about getting
better at using the dev list though and not just sending summaries
there. Thanks.

Replies to Adar Dembo:

Thanks for your comments. Just realize that some day you may not
be paid on a project to work on Kudu. Imagine then if you’d like
to contribute to Kudu and how it could be more welcoming. I’m just
trying to make that happen.


OK team, thanks a lot for listening.

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++





-----Original Message-----
From: jpluser <ch...@jpl.nasa.gov>
Reply-To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
Date: Monday, March 14, 2016 at 5:28 PM
To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
Subject: Re: Creating more actual (non-code-auto-emails) discussion on the
M/L

>Phew, mea culpa! I have zero clue why I never received the replies
>but I see them here:
>
>https://s.apache.org/vfw1
>
>I’ll be reading the replies now.
>
>Thanks, Todd.
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Chris Mattmann, Ph.D.
>Chief Architect
>Instrument Software and Science Data Systems Section (398)
>NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>Office: 168-519, Mailstop: 168-527
>Email: chris.a.mattmann@nasa.gov
>WWW:  http://sunset.usc.edu/~mattmann/
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Director, Information Retrieval and Data Science Group (IRDS)
>Adjunct Associate Professor, Computer Science Department
>University of Southern California, Los Angeles, CA 90089 USA
>WWW: http://irds.usc.edu/
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
>-----Original Message-----
>From: Todd Lipcon <to...@cloudera.com>
>Reply-To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
>Date: Monday, March 14, 2016 at 5:22 PM
>To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
>Subject: Re: Creating more actual (non-code-auto-emails) discussion on the
>M/L
>
>>Hey Chris,
>>
>>Maybe something's wrong with your email? There were several replies from
>>JD
>>Cryans, Mike Percy, Adar Dembo, and David Alves in this thread.
>>
>>-Todd
>>
>>On Mon, Mar 14, 2016 at 5:12 PM, Mattmann, Chris A (3980) <
>>chris.a.mattmann@jpl.nasa.gov> wrote:
>>
>>> I’m a bit worried that it’s been almost a week and not one person
>>> has discussed this here besides Todd and/or I. There are 9 committers
>>> and 7 mentors per [1]. Where is everybody?
>>>
>>> Cheers,
>>> Chris
>>>
>>> [1] http://incubator.apache.org/projects/kudu.html
>>>
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Chris Mattmann, Ph.D.
>>> Chief Architect
>>> Instrument Software and Science Data Systems Section (398)
>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>> Office: 168-519, Mailstop: 168-527
>>> Email: chris.a.mattmann@nasa.gov
>>> WWW:  http://sunset.usc.edu/~mattmann/
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Director, Information Retrieval and Data Science Group (IRDS)
>>> Adjunct Associate Professor, Computer Science Department
>>> University of Southern California, Los Angeles, CA 90089 USA
>>> WWW: http://irds.usc.edu/
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: jpluser <ch...@jpl.nasa.gov>
>>> Reply-To: "dev@kudu.incubator.apache.org"
>>><de...@kudu.incubator.apache.org>
>>> Date: Wednesday, March 9, 2016 at 8:00 PM
>>> To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
>>> Subject: Re: Creating more actual (non-code-auto-emails) discussion on
>>>the
>>> M/L
>>>
>>> >Thanks for the reply Todd. Unfortunately it's more systematic than
>>>that.
>>> >Apologies for top post but am on my phone. Couple points:
>>> >
>>> >- interested to hear from others besides you on this. No offense but I
>>> >think it's important that project members send email here to reply.
>>> >
>>> >- I hand counted the 4 threads of interest. Didn't run a fancy command
>>> >but to be honest it's more indicative of the broader issue. Things
>>>aren't
>>> >always solved through fancy greps and tools like gerrit. This is going
>>>to
>>> >be a core issue with Kudu's incubation - how is someone not sitting in
>>>a
>>> >cube working on the project who isn't on those tools like gerrit and
>>> >slack which don't exist at the ASF going to join on the project?
>>> >
>>> >- Even considering 40 threads I doubt there have only be <= 40
>>> >*decisions* on the project to date. IOW they are being made somewhere
>>>but
>>> >it's unclear where. Email is easy to follow on a phone on the go
>>> >whatever.
>>> >
>>> >As a mentor I would not be comfortable with Kudu being a TLP at this
>>> >point bc frankly projects need to use their dev list for more than
>>> >automated discussion and big reports. Simple as that and sending a
>>> >transcript of where convo is happening elsewhere is not going to cut
>>>it
>>> >unfortunately.
>>> >
>>> >Email is slow and deliberate and not as fast or slick as gerrit etc,
>>>but
>>> >that's a good thing. It allows people the time needed to read and join
>>>an
>>> >OSS community. It's too hard to do that with Kudu right now.
>>> >
>>> >Cheers,
>>> >Chris
>>> >
>>> >Sent from my iPhone
>>> >
>>> >> On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
>>> >>
>>> >> Hey Chris,
>>> >>
>>> >> Responses inline:
>>> >>
>>> >> On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
>>> >> chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org
>>> >>-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 issues@kudu.incubator.apache.org 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
>>>
>>>
>>
>>
>>-- 
>>Todd Lipcon
>>Software Engineer, Cloudera
>

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

["Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>]

Phew, mea culpa! I have zero clue why I never received the replies
but I see them here:

https://s.apache.org/vfw1

I’ll be reading the replies now.

Thanks, Todd.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++





-----Original Message-----
From: Todd Lipcon <to...@cloudera.com>
Reply-To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
Date: Monday, March 14, 2016 at 5:22 PM
To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
Subject: Re: Creating more actual (non-code-auto-emails) discussion on the
M/L

>Hey Chris,
>
>Maybe something's wrong with your email? There were several replies from
>JD
>Cryans, Mike Percy, Adar Dembo, and David Alves in this thread.
>
>-Todd
>
>On Mon, Mar 14, 2016 at 5:12 PM, Mattmann, Chris A (3980) <
>chris.a.mattmann@jpl.nasa.gov> wrote:
>
>> I’m a bit worried that it’s been almost a week and not one person
>> has discussed this here besides Todd and/or I. There are 9 committers
>> and 7 mentors per [1]. Where is everybody?
>>
>> Cheers,
>> Chris
>>
>> [1] http://incubator.apache.org/projects/kudu.html
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Chief Architect
>> Instrument Software and Science Data Systems Section (398)
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 168-519, Mailstop: 168-527
>> Email: chris.a.mattmann@nasa.gov
>> WWW:  http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Director, Information Retrieval and Data Science Group (IRDS)
>> Adjunct Associate Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> WWW: http://irds.usc.edu/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: jpluser <ch...@jpl.nasa.gov>
>> Reply-To: "dev@kudu.incubator.apache.org"
>><de...@kudu.incubator.apache.org>
>> Date: Wednesday, March 9, 2016 at 8:00 PM
>> To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
>> Subject: Re: Creating more actual (non-code-auto-emails) discussion on
>>the
>> M/L
>>
>> >Thanks for the reply Todd. Unfortunately it's more systematic than
>>that.
>> >Apologies for top post but am on my phone. Couple points:
>> >
>> >- interested to hear from others besides you on this. No offense but I
>> >think it's important that project members send email here to reply.
>> >
>> >- I hand counted the 4 threads of interest. Didn't run a fancy command
>> >but to be honest it's more indicative of the broader issue. Things
>>aren't
>> >always solved through fancy greps and tools like gerrit. This is going
>>to
>> >be a core issue with Kudu's incubation - how is someone not sitting in
>>a
>> >cube working on the project who isn't on those tools like gerrit and
>> >slack which don't exist at the ASF going to join on the project?
>> >
>> >- Even considering 40 threads I doubt there have only be <= 40
>> >*decisions* on the project to date. IOW they are being made somewhere
>>but
>> >it's unclear where. Email is easy to follow on a phone on the go
>> >whatever.
>> >
>> >As a mentor I would not be comfortable with Kudu being a TLP at this
>> >point bc frankly projects need to use their dev list for more than
>> >automated discussion and big reports. Simple as that and sending a
>> >transcript of where convo is happening elsewhere is not going to cut it
>> >unfortunately.
>> >
>> >Email is slow and deliberate and not as fast or slick as gerrit etc,
>>but
>> >that's a good thing. It allows people the time needed to read and join
>>an
>> >OSS community. It's too hard to do that with Kudu right now.
>> >
>> >Cheers,
>> >Chris
>> >
>> >Sent from my iPhone
>> >
>> >> On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
>> >>
>> >> Hey Chris,
>> >>
>> >> Responses inline:
>> >>
>> >> On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
>> >> chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org
>> >>-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 issues@kudu.incubator.apache.org 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
>>
>>
>
>
>-- 
>Todd Lipcon
>Software Engineer, Cloudera

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Todd Lipcon <to...@cloudera.com>]

Hey Chris,

Maybe something's wrong with your email? There were several replies from JD
Cryans, Mike Percy, Adar Dembo, and David Alves in this thread.

-Todd

On Mon, Mar 14, 2016 at 5:12 PM, Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov> wrote:

> I’m a bit worried that it’s been almost a week and not one person
> has discussed this here besides Todd and/or I. There are 9 committers
> and 7 mentors per [1]. Where is everybody?
>
> Cheers,
> Chris
>
> [1] http://incubator.apache.org/projects/kudu.html
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattmann@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Director, Information Retrieval and Data Science Group (IRDS)
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> WWW: http://irds.usc.edu/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
> -----Original Message-----
> From: jpluser <ch...@jpl.nasa.gov>
> Reply-To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
> Date: Wednesday, March 9, 2016 at 8:00 PM
> To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
> Subject: Re: Creating more actual (non-code-auto-emails) discussion on the
> M/L
>
> >Thanks for the reply Todd. Unfortunately it's more systematic than that.
> >Apologies for top post but am on my phone. Couple points:
> >
> >- interested to hear from others besides you on this. No offense but I
> >think it's important that project members send email here to reply.
> >
> >- I hand counted the 4 threads of interest. Didn't run a fancy command
> >but to be honest it's more indicative of the broader issue. Things aren't
> >always solved through fancy greps and tools like gerrit. This is going to
> >be a core issue with Kudu's incubation - how is someone not sitting in a
> >cube working on the project who isn't on those tools like gerrit and
> >slack which don't exist at the ASF going to join on the project?
> >
> >- Even considering 40 threads I doubt there have only be <= 40
> >*decisions* on the project to date. IOW they are being made somewhere but
> >it's unclear where. Email is easy to follow on a phone on the go
> >whatever.
> >
> >As a mentor I would not be comfortable with Kudu being a TLP at this
> >point bc frankly projects need to use their dev list for more than
> >automated discussion and big reports. Simple as that and sending a
> >transcript of where convo is happening elsewhere is not going to cut it
> >unfortunately.
> >
> >Email is slow and deliberate and not as fast or slick as gerrit etc, but
> >that's a good thing. It allows people the time needed to read and join an
> >OSS community. It's too hard to do that with Kudu right now.
> >
> >Cheers,
> >Chris
> >
> >Sent from my iPhone
> >
> >> On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
> >>
> >> Hey Chris,
> >>
> >> Responses inline:
> >>
> >> On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
> >> chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org
> >>-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 issues@kudu.incubator.apache.org 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
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

["Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>]

I’m a bit worried that it’s been almost a week and not one person
has discussed this here besides Todd and/or I. There are 9 committers
and 7 mentors per [1]. Where is everybody?

Cheers,
Chris

[1] http://incubator.apache.org/projects/kudu.html

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++





-----Original Message-----
From: jpluser <ch...@jpl.nasa.gov>
Reply-To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
Date: Wednesday, March 9, 2016 at 8:00 PM
To: "dev@kudu.incubator.apache.org" <de...@kudu.incubator.apache.org>
Subject: Re: Creating more actual (non-code-auto-emails) discussion on the
M/L

>Thanks for the reply Todd. Unfortunately it's more systematic than that.
>Apologies for top post but am on my phone. Couple points:
>
>- interested to hear from others besides you on this. No offense but I
>think it's important that project members send email here to reply.
>
>- I hand counted the 4 threads of interest. Didn't run a fancy command
>but to be honest it's more indicative of the broader issue. Things aren't
>always solved through fancy greps and tools like gerrit. This is going to
>be a core issue with Kudu's incubation - how is someone not sitting in a
>cube working on the project who isn't on those tools like gerrit and
>slack which don't exist at the ASF going to join on the project?
>
>- Even considering 40 threads I doubt there have only be <= 40
>*decisions* on the project to date. IOW they are being made somewhere but
>it's unclear where. Email is easy to follow on a phone on the go
>whatever. 
>
>As a mentor I would not be comfortable with Kudu being a TLP at this
>point bc frankly projects need to use their dev list for more than
>automated discussion and big reports. Simple as that and sending a
>transcript of where convo is happening elsewhere is not going to cut it
>unfortunately.
>
>Email is slow and deliberate and not as fast or slick as gerrit etc, but
>that's a good thing. It allows people the time needed to read and join an
>OSS community. It's too hard to do that with Kudu right now.
>
>Cheers,
>Chris 
>
>Sent from my iPhone
>
>> On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
>> 
>> Hey Chris,
>> 
>> Responses inline:
>> 
>> On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
>> chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org
>>-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 issues@kudu.incubator.apache.org 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

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Jean-Daniel Cryans <jd...@apache.org>]

On Thu, Mar 10, 2016 at 8:02 AM, Jean-Daniel Cryans <jd...@apache.org>
wrote:

> In general, I agree that dev@ should be a discussion forum and automated
> traffic should go elsewhere. I'm in favor of having a reviews@.
>
> On Wed, Mar 9, 2016 at 7:00 PM, Mattmann, Chris A (3980) <
> chris.a.mattmann@jpl.nasa.gov> wrote:
>
>> Thanks for the reply Todd. Unfortunately it's more systematic than that.
>> Apologies for top post but am on my phone. Couple points:
>>
>> - interested to hear from others besides you on this. No offense but I
>> think it's important that project members send email here to reply.
>>
>> - I hand counted the 4 threads of interest. Didn't run a fancy command
>> but to be honest it's more indicative of the broader issue. Things aren't
>> always solved through fancy greps and tools like gerrit. This is going to
>> be a core issue with Kudu's incubation - how is someone not sitting in a
>> cube working on the project who isn't on those tools like gerrit and slack
>> which don't exist at the ASF going to join on the project?
>>
>
> What is this, the 90s? We're all in one big open room :)
>
> But more seriously, and I'm asking because I'm not sure I understand, if
> something is "inside the ASF" is it good enough that it doesn't also need
> to be on a mailing list? My previous ASF experience is with HBase, where
> mail from reviews.apache.org doesn't go to any list (as far as I can
> tell). The dev list I'd say is in a more healthy state, but way back I
> remember a decision was made to at least keep the "jira status changes"
> like CREATED and RESOLVED to keep going there so that people are aware of
> what's going on since that community is very Jira-centric. But, the Jira
> instance is also inside the walls of the ASF.
>

Answering myself, HBase's review emails go to Jira, which goes to issues@.
Works well when 1 Jira = 1 patch.


>
>
>>
>> - Even considering 40 threads I doubt there have only be <= 40
>> *decisions* on the project to date. IOW they are being made somewhere but
>> it's unclear where. Email is easy to follow on a phone on the go whatever.
>>
>
> TBH there hasn't been that many decisions since incubation, a lot of what
> we're working on at least on the Cloudera side is stuff found in the design
> docs Mike is referring to that we just pick and go with. It's true that a
> lot of the finer grained discussions take place on gerrit.
>
>
>>
>> As a mentor I would not be comfortable with Kudu being a TLP at this
>> point bc frankly projects need to use their dev list for more than
>> automated discussion and big reports. Simple as that and sending a
>> transcript of where convo is happening elsewhere is not going to cut it
>> unfortunately.
>>
>
> You're right, we need to be better at this.
>
>
>>
>> Email is slow and deliberate and not as fast or slick as gerrit etc, but
>> that's a good thing. It allows people the time needed to read and join an
>> OSS community. It's too hard to do that with Kudu right now.
>>
>> Cheers,
>> Chris
>>
>> Sent from my iPhone
>>
>> > On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
>> >
>> > Hey Chris,
>> >
>> > Responses inline:
>> >
>> > On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
>> > chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org
>> -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 issues@kudu.incubator.apache.org 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
>>
>
>

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Jean-Daniel Cryans <jd...@apache.org>]

In general, I agree that dev@ should be a discussion forum and automated
traffic should go elsewhere. I'm in favor of having a reviews@.

On Wed, Mar 9, 2016 at 7:00 PM, Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov> wrote:

> Thanks for the reply Todd. Unfortunately it's more systematic than that.
> Apologies for top post but am on my phone. Couple points:
>
> - interested to hear from others besides you on this. No offense but I
> think it's important that project members send email here to reply.
>
> - I hand counted the 4 threads of interest. Didn't run a fancy command but
> to be honest it's more indicative of the broader issue. Things aren't
> always solved through fancy greps and tools like gerrit. This is going to
> be a core issue with Kudu's incubation - how is someone not sitting in a
> cube working on the project who isn't on those tools like gerrit and slack
> which don't exist at the ASF going to join on the project?
>

What is this, the 90s? We're all in one big open room :)

But more seriously, and I'm asking because I'm not sure I understand, if
something is "inside the ASF" is it good enough that it doesn't also need
to be on a mailing list? My previous ASF experience is with HBase, where
mail from reviews.apache.org doesn't go to any list (as far as I can tell).
The dev list I'd say is in a more healthy state, but way back I remember a
decision was made to at least keep the "jira status changes" like CREATED
and RESOLVED to keep going there so that people are aware of what's going
on since that community is very Jira-centric. But, the Jira instance is
also inside the walls of the ASF.


>
> - Even considering 40 threads I doubt there have only be <= 40 *decisions*
> on the project to date. IOW they are being made somewhere but it's unclear
> where. Email is easy to follow on a phone on the go whatever.
>

TBH there hasn't been that many decisions since incubation, a lot of what
we're working on at least on the Cloudera side is stuff found in the design
docs Mike is referring to that we just pick and go with. It's true that a
lot of the finer grained discussions take place on gerrit.


>
> As a mentor I would not be comfortable with Kudu being a TLP at this point
> bc frankly projects need to use their dev list for more than automated
> discussion and big reports. Simple as that and sending a transcript of
> where convo is happening elsewhere is not going to cut it unfortunately.
>

You're right, we need to be better at this.


>
> Email is slow and deliberate and not as fast or slick as gerrit etc, but
> that's a good thing. It allows people the time needed to read and join an
> OSS community. It's too hard to do that with Kudu right now.
>
> Cheers,
> Chris
>
> Sent from my iPhone
>
> > On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
> >
> > Hey Chris,
> >
> > Responses inline:
> >
> > On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
> > chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org
> -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 issues@kudu.incubator.apache.org 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
>

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

["Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>]

Thanks for the reply Todd. Unfortunately it's more systematic than that. Apologies for top post but am on my phone. Couple points:

- interested to hear from others besides you on this. No offense but I think it's important that project members send email here to reply.

- I hand counted the 4 threads of interest. Didn't run a fancy command but to be honest it's more indicative of the broader issue. Things aren't always solved through fancy greps and tools like gerrit. This is going to be a core issue with Kudu's incubation - how is someone not sitting in a cube working on the project who isn't on those tools like gerrit and slack which don't exist at the ASF going to join on the project?

- Even considering 40 threads I doubt there have only be <= 40 *decisions* on the project to date. IOW they are being made somewhere but it's unclear where. Email is easy to follow on a phone on the go whatever. 

As a mentor I would not be comfortable with Kudu being a TLP at this point bc frankly projects need to use their dev list for more than automated discussion and big reports. Simple as that and sending a transcript of where convo is happening elsewhere is not going to cut it unfortunately.

Email is slow and deliberate and not as fast or slick as gerrit etc, but that's a good thing. It allows people the time needed to read and join an OSS community. It's too hard to do that with Kudu right now.

Cheers,
Chris 

Sent from my iPhone

> On Mar 9, 2016, at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:
> 
> Hey Chris,
> 
> Responses inline:
> 
> On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
> chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org -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 issues@kudu.incubator.apache.org 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

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Todd Lipcon <to...@apache.org>]

On Wed, Mar 9, 2016 at 6:46 PM, Todd Lipcon <to...@apache.org> wrote:

>
> Hmm, I did a search in my inbox for: dev@kudu.incubator.apache.org
> -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.
>
>

As another quick data point, I searched for:  (hdfs-dev@hadoop.apache.org |
common-dev@hadoop.apache.org) -jira@apache.org -jenkins -"hadoop pull
request" after:2016/1/1
and found 42 threads. So, I think in terms of total amount of discussion
happening on the mailing list, we're actually not far behind other active
projects. I think it's more likely that it's what you said -- harder to
find amidst the JIRA/gerrit traffic which more casual contributors might
not be interested in.

-Todd

Re: Creating more actual (non-code-auto-emails) discussion on the M/L

[Todd Lipcon <to...@apache.org>]

Hey Chris,

Responses inline:

On Wed, Mar 9, 2016 at 6:08 PM, Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov> 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: dev@kudu.incubator.apache.org -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 issues@kudu.incubator.apache.org 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