metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Artem Ervits <artemerv...@gmail.com>
Subject Re: [DISCUSS] Easing the ramp-up into contributing
Date Fri, 28 Jul 2017 17:05:27 GMT
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