metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <>
Subject Re: [DISCUSS] Easing the ramp-up into contributing
Date Thu, 27 Jul 2017 17:36:42 GMT
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 ( 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 <> 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
> 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
> > hurdles are to contributing and working on contributions. I'd like to
> make
> > it easier for everyone to dive right in and make contributions
> > the project (and even just get information about what we're building).
> >
> > We've been incrementally working on this with some great stuff (The
> > book, perf tuning guide, some cleanup around organization, etc.) and
> > 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 (
> >, 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

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