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, zeo...@gmail.com <zeo...@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 <ottobackwa...@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 >
