metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Leet <justinjl...@gmail.com>
Subject Re: [DISCUSS] Easing the ramp-up into contributing
Date Fri, 28 Jul 2017 18:53:26 GMT
I created METRON-1071 <https://issues.apache.org/jira/browse/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.miklavcic@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 <artemervits@gmail.com>
> 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 <ottobackwards@gmail.com>
>> wrote:
>>
>> > +1 for CONTRIBUTING.md
>> >
>> >
>> > On July 28, 2017 at 09:14:38, Justin Leet (justinjleet@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 <mfoley@hortonworks.com>
>> > 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" <ottobackwards@gmail.com> 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 (nick@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 Zeolla@GMail.com <zeolla@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 <justinjleet@gmail.com
>> >
>> > > > 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
>> > > >
>> > >
>> > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message