metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <mfo...@hortonworks.com>
Subject Re: [DISCUSS] Easing the ramp-up into contributing
Date Thu, 27 Jul 2017 19:33:55 GMT
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
View raw message