metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Stella <ceste...@gmail.com>
Subject Re: [DISCUSS] Resources for how to contribute to Apache Metron
Date Wed, 20 Dec 2017 15:36:58 GMT
That's really good feedback, Jon.  I agree that we have a significant
barrier to get to the point of tinkering.  Full-dev really wasn't intended
to be that entry point; it's more of a way to test PRs in something
resembling a realistic scenario (and it is still not super realistic).  I
would welcome creative ideas around how to accomplish that goal.

On Wed, Dec 20, 2017 at 10:15 AM, Zeolla@GMail.com <zeolla@gmail.com> wrote:

> For nearly everybody I've talked to about this project that had complaints,
> I've heard something about the significant barrier to entry, divided into
> two general categories.  Category 1 is that a lot of security teams lack
> substantial experience with Hadoop and would like to get a better
> understanding of how the involved components fit together - not
> just kafka goes to storm goes to kafka, or a link to the kafka docs for
> details about kafka, but a little bit more detail as to _why_ those
> components are in use in metron, what properties those components possess
> at a high level _which makes them appealing to us_, and how they're
> _currently used_ in the metron environment.  Category 2 is that it is
> generally more difficult than it should be to get a testing/poc environment
> running - running it on a laptop (especially non-macOS) can be a pain to
> get running, some laptops simply cannot run it, etc.  I've heard a few
> times that a company uses Azure (not AWS) and they would like to quickly
> spin it up there.
>
> Just my $0.02
>
> Jon
>
> On Tue, Dec 19, 2017 at 9:02 AM Otto Fowler <ottobackwards@gmail.com>
> wrote:
>
> > Like any project, Apache Metron needs to maintain and grow it’s
> contributor
> > community. We think that we could be doing a better job of this, and
> would
> > like to discuss issues and possible improvements. Issues
> >
> > What are some of the issues that may inhibit people contributing?
> >
> >    - Barrier of entry (issues getting Metron running in vagrant or local)
> >    - Documentation : finding current
> >    - Documentation : content and quality
> >    - Source Code navigation/documentation/guides
> >    - Testing guides
> >    - Use Case Guides
> >    - Don’t know how they *can* contribute
> >    - Others that I’m missing?
> >
> > Remediation Barrier of entry
> >
> > How can we make the local deployment workflow easier ( other discuss
> thread
> > touches on this)?
> > Documentation : Finding Current
> >
> > When people look for Metron info, where are they looking? What comes up
> in
> > search? - Hortonworks Community forums ( preview release stuff ? ), old
> > blog posts? - Mailing list archives? - wiki? (not current) - site-book?
> >
> > How can we reduce the out of data information, and make the relevant
> > information more prominent?
> > Documentation : Content and Quality
> >
> > ( this is a little bit of a chicken and egg issue, since documentation
> is a
> > wonderful way to contribute…. ) - Up to data architecture documentation -
> > Non-developer focused ‘feature’ documentation - Developer focused
> > documentation ( how to add a XXXXXX guides )
> > Source Code Guides
> >
> >    - Structure of the code tree
> >    - What is where, how it is logically setup
> >    - How to maintain concistancy when working in the code
> >    - Javadoc
> >
> > Testing Guides
> >
> >    - Tests that we have are buried in PR’s
> >    - No regression tests
> >
> > Use case guides
> >
> >    - more how-to guides
> >
> > Contributing guide
> >
> >    - right now, have dev env guide
> >    - review and submit doc changes
> >    - review PR guide
> >    - pr testing guide ( better pr testing steps?)
> >
> > These are things I can think of, anyone have any comment, additions,
> > priorities?
> >
> --
>
> Jon
>

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