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 <[email protected]> wrote: > +1 for CONTRIBUTING.md > > > On July 28, 2017 at 09:14:38, Justin Leet ([email protected]) 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 <[email protected]> > 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" <[email protected]> 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 ([email protected]) 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 [email protected] <[email protected]> > > 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 <[email protected]> > > > 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 > > > > > > > > > >
