I created METRON-1071 <https://issues.apache.org/jira/browse/METRON-1071> to track the CONTRIBUTING.md. I also called out personal Travis setup instructions, because that's pretty closely tied our dev experience and seems like a good place to let it live.
On Fri, Jul 28, 2017 at 1:43 PM, Michael Miklavcic < michael.miklav...@gmail.com> wrote: > Hi Artem, You could probably get away with not running them locally since > we use Travis, which functions similarly to Jenkins from a testing > perspective. Additionally, you can hook up Travis to run on your own github > account as many Metron committers have already done. The upshot is that if > your PR breaks an unrelated test, it would be up to you to debug and fix > before it's able to be +1'ed and committed. Does that make sense? > > Best, > Mike > > On Fri, Jul 28, 2017 at 11:05 AM, Artem Ervits <artemerv...@gmail.com> > wrote: > >> 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 <ottobackwa...@gmail.com> >> wrote: >> >> > +1 for CONTRIBUTING.md >> > >> > >> > On July 28, 2017 at 09:14:38, Justin Leet (justinjl...@gmail.com) >> 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 <mfo...@hortonworks.com> >> > 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" <ottobackwa...@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 (n...@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 zeo...@gmail.com <zeo...@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 <justinjl...@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 >> > > > >> > > >> > > >> > > >> > >> > >
