Re: [DISCUSS] Easing the ramp-up into contributing

[Justin Leet]

I created METRON-1071  to
track the CONTRIBUTING.md.  I also called out personal Travis setup
instructions, because that's pretty closely tied our dev experience and
seems like a good place to let it live.

On Fri, Jul 28, 2017 at 1:43 PM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> Hi Artem, You could probably get away with not running them locally since
> we use Travis, which functions similarly to Jenkins from a testing
> perspective. Additionally, you can hook up Travis to run on your own github
> account as many Metron committers have already done. The upshot is that if
> your PR breaks an unrelated test, it would be up to you to debug and fix
> before it's able to be +1'ed and committed. Does that make sense?
>
> Best,
> Mike
>
> On Fri, Jul 28, 2017 at 11:05 AM, Artem Ervits 
> wrote:
>
>> Being new to this community and attempting to contribute METRON-1058,
>> METRON-1059 and METRON-1063, my experience is that requirement to run the
>> full tests and integration tests in order to contribute even a simple
>> patch
>> is overkill. I understand that community wants high quality contributions
>> but leaving the burden of running full test suites to a contributor is too
>> much. I've contributed to other communities and hurdle of running full
>> tests were on Jenkins side.
>> my 2c.
>>
>> On Fri, Jul 28, 2017 at 11:51 AM, Otto Fowler 
>> wrote:
>>
>> > +1 for CONTRIBUTING.md
>> >
>> >
>> > On July 28, 2017 at 09:14:38, Justin Leet (justinjl...@gmail.com)
>> wrote:
>> >
>> > I'm gonna break replies into chunks, since I'm responding to a few
>> people
>> > here.
>> >
>> > Re Nick:
>> > I'm honesty not sure how we'd want to improve that portion of the
>> landing
>> > experience, and I'm going to be totally honest the elevator pitch
>> > articulation of things is something I'm notably awful at. Having said
>> > that, I guarantee if that's your thought; other people have thought the
>> > same thing. I'd be cool with having an improved "What is Metron?", but
>> I'd
>> > probably need someone else to at least start that discussion up before I
>> > have a particularly useful opinion.
>> >
>> > Re Otto:
>> > What do we think about adding a CONTRIBUTING.md file, rolling it into
>> the
>> > site-book, and adding a short blurb linking to it on the main README.md?
>> > Github talks about it here:
>> > https://github.com/blog/1184-contributing-guidelines.
>> >
>> > I think this is also a good way to roll in Otto's comment about
>> encouraging
>> > reviews of PRs and emphasizing that we're definitely accepting of
>> > contributions across all spectrums.
>> >
>> > At that point, I think people should pretty easily be able to find it
>> from
>> > the main landing page and get a good overview of how people can hop in
>> and
>> > help. If we think that would be helpful, I'm happy to create a jira and
>> > grab it, even if it might take a bit to get to. It's also a good way to
>> > migrate of that info out of the wiki like Jon mentioned.
>> >
>> > Re Matt:
>> > Thanks for taking offering to take a look at it. I agree, I don't think
>> > it's the most important thing, but it is (hopefully) a pretty low
>> hanging
>> > fruit that provides value to people just hopping in (or even hopping
>> into a
>> > new area). I think the label is a good idea, because I think we're
>> > probably going to start having tickets to improve and clean some of
>> that up
>> > as we mature.
>> >
>> > On Thu, Jul 27, 2017 at 3:33 PM, Matt Foley 
>> > wrote:
>> >
>> > > Really good discussion thread, thanks for opening it Justin.
>> > >
>> > > I’m a fan of adding javadocs to the publicly available doc set. It’s
>> not
>> > > the most important of the items listed below, but it is easy, and will
>> > push
>> > > people to be more attentive to dev documentation.
>> > >
>> > > METRON-759 is open for that, and I’ll take a crack at it.
>> > > I also suggest we start using “javadoc” (NOT “javadocs” plural) as a
>> > Label
>> > > on javadoc-related jiras.
>> > >
>> > > --Matt
>> > >
>> > > On 7/27/17, 10:36 AM, "Otto Fowler"  wrote:
>> > >
>> > > Beyond this, I think we need to encourage PR review and testing as a
>> > > way to
>> > > contribute, along with documentation. So things
>> > > that help with those topics will be good. Maybe an expended "ways to
>> > > get
>> > > involved including”, and why they are important.
>> > >
>> > > Increased participation leading to PR’s that don’t get reviewed and
>> > > committed is not where we want to land.
>> > >
>> > > On July 27, 2017 at 11:51:35, Nick Allen (n...@nickallen.org) wrote:
>> > >
>> > > Good discussion to bring up Justin. All good suggestions on your part.
>> > >
>> > > One I'd add is that I'd like to see us improve the "What the heck is
>> > > Metron?" experience. Right now after looking at our home page or
>> GitHub
>> > > repo I really 

Re: [DISCUSS] Easing the ramp-up into contributing

[Michael Miklavcic]

Hi Artem, You could probably get away with not running them locally since
we use Travis, which functions similarly to Jenkins from a testing
perspective. Additionally, you can hook up Travis to run on your own github
account as many Metron committers have already done. The upshot is that if
your PR breaks an unrelated test, it would be up to you to debug and fix
before it's able to be +1'ed and committed. Does that make sense?

Best,
Mike

On Fri, Jul 28, 2017 at 11:05 AM, Artem Ervits 
wrote:

> Being new to this community and attempting to contribute METRON-1058,
> METRON-1059 and METRON-1063, my experience is that requirement to run the
> full tests and integration tests in order to contribute even a simple patch
> is overkill. I understand that community wants high quality contributions
> but leaving the burden of running full test suites to a contributor is too
> much. I've contributed to other communities and hurdle of running full
> tests were on Jenkins side.
> my 2c.
>
> On Fri, Jul 28, 2017 at 11:51 AM, Otto Fowler 
> wrote:
>
> > +1 for CONTRIBUTING.md
> >
> >
> > On July 28, 2017 at 09:14:38, Justin Leet (justinjl...@gmail.com) wrote:
> >
> > I'm gonna break replies into chunks, since I'm responding to a few people
> > here.
> >
> > Re Nick:
> > I'm honesty not sure how we'd want to improve that portion of the landing
> > experience, and I'm going to be totally honest the elevator pitch
> > articulation of things is something I'm notably awful at. Having said
> > that, I guarantee if that's your thought; other people have thought the
> > same thing. I'd be cool with having an improved "What is Metron?", but
> I'd
> > probably need someone else to at least start that discussion up before I
> > have a particularly useful opinion.
> >
> > Re Otto:
> > What do we think about adding a CONTRIBUTING.md file, rolling it into the
> > site-book, and adding a short blurb linking to it on the main README.md?
> > Github talks about it here:
> > https://github.com/blog/1184-contributing-guidelines.
> >
> > I think this is also a good way to roll in Otto's comment about
> encouraging
> > reviews of PRs and emphasizing that we're definitely accepting of
> > contributions across all spectrums.
> >
> > At that point, I think people should pretty easily be able to find it
> from
> > the main landing page and get a good overview of how people can hop in
> and
> > help. If we think that would be helpful, I'm happy to create a jira and
> > grab it, even if it might take a bit to get to. It's also a good way to
> > migrate of that info out of the wiki like Jon mentioned.
> >
> > Re Matt:
> > Thanks for taking offering to take a look at it. I agree, I don't think
> > it's the most important thing, but it is (hopefully) a pretty low hanging
> > fruit that provides value to people just hopping in (or even hopping
> into a
> > new area). I think the label is a good idea, because I think we're
> > probably going to start having tickets to improve and clean some of that
> up
> > as we mature.
> >
> > On Thu, Jul 27, 2017 at 3:33 PM, Matt Foley 
> > wrote:
> >
> > > Really good discussion thread, thanks for opening it Justin.
> > >
> > > I’m a fan of adding javadocs to the publicly available doc set. It’s
> not
> > > the most important of the items listed below, but it is easy, and will
> > push
> > > people to be more attentive to dev documentation.
> > >
> > > METRON-759 is open for that, and I’ll take a crack at it.
> > > I also suggest we start using “javadoc” (NOT “javadocs” plural) as a
> > Label
> > > on javadoc-related jiras.
> > >
> > > --Matt
> > >
> > > On 7/27/17, 10:36 AM, "Otto Fowler"  wrote:
> > >
> > > Beyond this, I think we need to encourage PR review and testing as a
> > > way to
> > > contribute, along with documentation. So things
> > > that help with those topics will be good. Maybe an expended "ways to
> > > get
> > > involved including”, and why they are important.
> > >
> > > Increased participation leading to PR’s that don’t get reviewed and
> > > committed is not where we want to land.
> > >
> > > On July 27, 2017 at 11:51:35, Nick Allen (n...@nickallen.org) wrote:
> > >
> > > Good discussion to bring up Justin. All good suggestions on your part.
> > >
> > > One I'd add is that I'd like to see us improve the "What the heck is
> > > Metron?" experience. Right now after looking at our home page or GitHub
> > > repo I really don't understand what Metron does and why I should be
> > > interested in it. Improving this would drive more users and
> > > contributors.
> > >
> > > Slightly adjacent maybe to your original discussion point, but I
> > > thought
> > > worth mentioning.
> > >
> > > On Thu, Jul 27, 2017, 9:52 AM zeo...@gmail.com 
> > > wrote:
> > >
> > > > I'm totally in agreement here, and I would add to the list the
> > > migration
> > > > from the wiki to the site-book. There 

Re: [DISCUSS] Easing the ramp-up into contributing

[Artem Ervits]

Being new to this community and attempting to contribute METRON-1058,
METRON-1059 and METRON-1063, my experience is that requirement to run the
full tests and integration tests in order to contribute even a simple patch
is overkill. I understand that community wants high quality contributions
but leaving the burden of running full test suites to a contributor is too
much. I've contributed to other communities and hurdle of running full
tests were on Jenkins side.
my 2c.

On Fri, Jul 28, 2017 at 11:51 AM, Otto Fowler 
wrote:

> +1 for CONTRIBUTING.md
>
>
> On July 28, 2017 at 09:14:38, Justin Leet (justinjl...@gmail.com) wrote:
>
> I'm gonna break replies into chunks, since I'm responding to a few people
> here.
>
> Re Nick:
> I'm honesty not sure how we'd want to improve that portion of the landing
> experience, and I'm going to be totally honest the elevator pitch
> articulation of things is something I'm notably awful at. Having said
> that, I guarantee if that's your thought; other people have thought the
> same thing. I'd be cool with having an improved "What is Metron?", but I'd
> probably need someone else to at least start that discussion up before I
> have a particularly useful opinion.
>
> Re Otto:
> What do we think about adding a CONTRIBUTING.md file, rolling it into the
> site-book, and adding a short blurb linking to it on the main README.md?
> Github talks about it here:
> https://github.com/blog/1184-contributing-guidelines.
>
> I think this is also a good way to roll in Otto's comment about encouraging
> reviews of PRs and emphasizing that we're definitely accepting of
> contributions across all spectrums.
>
> At that point, I think people should pretty easily be able to find it from
> the main landing page and get a good overview of how people can hop in and
> help. If we think that would be helpful, I'm happy to create a jira and
> grab it, even if it might take a bit to get to. It's also a good way to
> migrate of that info out of the wiki like Jon mentioned.
>
> Re Matt:
> Thanks for taking offering to take a look at it. I agree, I don't think
> it's the most important thing, but it is (hopefully) a pretty low hanging
> fruit that provides value to people just hopping in (or even hopping into a
> new area). I think the label is a good idea, because I think we're
> probably going to start having tickets to improve and clean some of that up
> as we mature.
>
> On Thu, Jul 27, 2017 at 3:33 PM, Matt Foley 
> wrote:
>
> > Really good discussion thread, thanks for opening it Justin.
> >
> > I’m a fan of adding javadocs to the publicly available doc set. It’s not
> > the most important of the items listed below, but it is easy, and will
> push
> > people to be more attentive to dev documentation.
> >
> > METRON-759 is open for that, and I’ll take a crack at it.
> > I also suggest we start using “javadoc” (NOT “javadocs” plural) as a
> Label
> > on javadoc-related jiras.
> >
> > --Matt
> >
> > On 7/27/17, 10:36 AM, "Otto Fowler"  wrote:
> >
> > Beyond this, I think we need to encourage PR review and testing as a
> > way to
> > contribute, along with documentation. So things
> > that help with those topics will be good. Maybe an expended "ways to
> > get
> > involved including”, and why they are important.
> >
> > Increased participation leading to PR’s that don’t get reviewed and
> > committed is not where we want to land.
> >
> > On July 27, 2017 at 11:51:35, Nick Allen (n...@nickallen.org) wrote:
> >
> > Good discussion to bring up Justin. All good suggestions on your part.
> >
> > One I'd add is that I'd like to see us improve the "What the heck is
> > Metron?" experience. Right now after looking at our home page or GitHub
> > repo I really don't understand what Metron does and why I should be
> > interested in it. Improving this would drive more users and
> > contributors.
> >
> > Slightly adjacent maybe to your original discussion point, but I
> > thought
> > worth mentioning.
> >
> > On Thu, Jul 27, 2017, 9:52 AM zeo...@gmail.com 
> > wrote:
> >
> > > I'm totally in agreement here, and I would add to the list the
> > migration
> > > from the wiki to the site-book. There were some prior email
> > conversations
> > > on this, some of which I started and then didn't follow up on, but I
> > see
> > > this as pretty important and I'm still interested in doing the
> > work/helping
> > > as time allows.
> > >
> > > Jon
> > >
> > > On Thu, Jul 27, 2017 at 10:48 AM Justin Leet 
> > > wrote:
> > >
> > > > I wanted to start a discussion and get some thoughts on what some
> > of
> > the
> > > > hurdles are to contributing and working on contributions. I'd like
> > to
> > > make
> > > > it easier for everyone to dive right in and make contributions
> > throughout
> > > > the project (and even just get information about what we're
> > building).
> > > >
> > > > We've been incrementally 

Re: [DISCUSS] Easing the ramp-up into contributing

[Matt Foley]

Really good discussion thread, thanks for opening it Justin.

I’m a fan of adding javadocs to the publicly available doc set.  It’s not the 
most important of the items listed below, but it is easy, and will push people 
to be more attentive to dev documentation.

METRON-759 is open for that, and I’ll take a crack at it.
I also suggest we start using “javadoc” (NOT “javadocs” plural) as a Label on 
javadoc-related jiras.

--Matt

On 7/27/17, 10:36 AM, "Otto Fowler"  wrote:

Beyond this, I think we need to encourage PR review and testing as a way to
contribute, along with documentation. So things
that help with those topics will be good.  Maybe an expended "ways to get
involved including”, and why they are important.

Increased participation leading to PR’s that don’t get reviewed and
committed is not where we want to land.

On July 27, 2017 at 11:51:35, Nick Allen (n...@nickallen.org) wrote:

Good discussion to bring up Justin. All good suggestions on your part.

One I'd add is that I'd like to see us improve the "What the heck is
Metron?" experience. Right now after looking at our home page or GitHub
repo I really don't understand what Metron does and why I should be
interested in it. Improving this would drive more users and contributors.

Slightly adjacent maybe to your original discussion point, but I thought
worth mentioning.

On Thu, Jul 27, 2017, 9:52 AM zeo...@gmail.com  wrote:

> I'm totally in agreement here, and I would add to the list the migration
> from the wiki to the site-book. There were some prior email conversations
> on this, some of which I started and then didn't follow up on, but I see
> this as pretty important and I'm still interested in doing the
work/helping
> as time allows.
>
> Jon
>
> On Thu, Jul 27, 2017 at 10:48 AM Justin Leet 
> wrote:
>
> > I wanted to start a discussion and get some thoughts on what some of
the
> > hurdles are to contributing and working on contributions. I'd like to
> make
> > it easier for everyone to dive right in and make contributions
throughout
> > the project (and even just get information about what we're building).
> >
> > We've been incrementally working on this with some great stuff (The
site
> > book, perf tuning guide, some cleanup around organization, etc.) and
it'd
> > be nice to keep that momentum going.
> >
> > Here's a couple things off the top of my head that I thought of. Feel
> free
> > to expand, agree, disagree, etc.:
> >
> > - Link the site-book more prominently, probably on the GitHub landing
> > page. It takes a few hops to find right now (or I'm not finding the
> > right
> > hops, which is its own potential hurdle).
> > - In the same vein, link to the contributing docs on the main landing
> > README. It should be immediately obvious where to go to start being
> > able to
> > contribute.
> > - Improve our Javadocs and general Maven reporting and make them more
> > generally discoverable? I know a lot of this is continually in flux as
> > we've been building and improving even foundational things, so we'd
> > probably want to be careful about how much we want to do here.
> > - Improve Ambari dev docs. I started that with (
> > https://github.com/apache/metron/pull/673), but I know there's more
> to
> > flesh out there. Feel free to hop on the comments of that. I'd love to
> > hear
> > what first impression hurdles are, even (especially?) if you haven't
> > touched mpack)
> > - Guides on debugging. We've been doing a couple things, but we need
> to
> > make it easier to find and diagnose problems, imo. A lot of this is
> > debugging of our dependencies, but ultimately we need to at least
> give a
> > starting point into digging into that type of thing.
> > - We've been improving the "How do I just spin something up and see it
> > work" experience and decreasing confusion around options, but I'm sure
> > there's more we can do here (Suggestions?)
> > - Tribal knowledge in general. I'd list specifics, but I don't know
> > them because they aren't documented.
> >
> > I'd love to see this list expanded with thoughts and even tickets.
> >
> --
>
> Jon
>

Re: [DISCUSS] Easing the ramp-up into contributing

[Otto Fowler]

Beyond this, I think we need to encourage PR review and testing as a way to
contribute, along with documentation. So things
that help with those topics will be good.  Maybe an expended "ways to get
involved including”, and why they are important.

Increased participation leading to PR’s that don’t get reviewed and
committed is not where we want to land.

On July 27, 2017 at 11:51:35, Nick Allen (n...@nickallen.org) wrote:

Good discussion to bring up Justin. All good suggestions on your part.

One I'd add is that I'd like to see us improve the "What the heck is
Metron?" experience. Right now after looking at our home page or GitHub
repo I really don't understand what Metron does and why I should be
interested in it. Improving this would drive more users and contributors.

Slightly adjacent maybe to your original discussion point, but I thought
worth mentioning.

On Thu, Jul 27, 2017, 9:52 AM zeo...@gmail.com  wrote:

> I'm totally in agreement here, and I would add to the list the migration
> from the wiki to the site-book. There were some prior email conversations
> on this, some of which I started and then didn't follow up on, but I see
> this as pretty important and I'm still interested in doing the
work/helping
> as time allows.
>
> Jon
>
> On Thu, Jul 27, 2017 at 10:48 AM Justin Leet 
> wrote:
>
> > I wanted to start a discussion and get some thoughts on what some of
the
> > hurdles are to contributing and working on contributions. I'd like to
> make
> > it easier for everyone to dive right in and make contributions
throughout
> > the project (and even just get information about what we're building).
> >
> > We've been incrementally working on this with some great stuff (The
site
> > book, perf tuning guide, some cleanup around organization, etc.) and
it'd
> > be nice to keep that momentum going.
> >
> > Here's a couple things off the top of my head that I thought of. Feel
> free
> > to expand, agree, disagree, etc.:
> >
> > - Link the site-book more prominently, probably on the GitHub landing
> > page. It takes a few hops to find right now (or I'm not finding the
> > right
> > hops, which is its own potential hurdle).
> > - In the same vein, link to the contributing docs on the main landing
> > README. It should be immediately obvious where to go to start being
> > able to
> > contribute.
> > - Improve our Javadocs and general Maven reporting and make them more
> > generally discoverable? I know a lot of this is continually in flux as
> > we've been building and improving even foundational things, so we'd
> > probably want to be careful about how much we want to do here.
> > - Improve Ambari dev docs. I started that with (
> > https://github.com/apache/metron/pull/673), but I know there's more
> to
> > flesh out there. Feel free to hop on the comments of that. I'd love to
> > hear
> > what first impression hurdles are, even (especially?) if you haven't
> > touched mpack)
> > - Guides on debugging. We've been doing a couple things, but we need
> to
> > make it easier to find and diagnose problems, imo. A lot of this is
> > debugging of our dependencies, but ultimately we need to at least
> give a
> > starting point into digging into that type of thing.
> > - We've been improving the "How do I just spin something up and see it
> > work" experience and decreasing confusion around options, but I'm sure
> > there's more we can do here (Suggestions?)
> > - Tribal knowledge in general. I'd list specifics, but I don't know
> > them because they aren't documented.
> >
> > I'd love to see this list expanded with thoughts and even tickets.
> >
> --
>
> Jon
>