In any event, I think creating JIRA ticket (regardless of how right/wrong it may be) would be appropriate in such settings as well as producing a fix and a PR/Patch essentially allowing it to be vetted by ASF process. On the other hand I also hear Tony’s point about "short turnaround”. Certain issues may be very obvious (e.g., NPEs, spelling, misconfiguration etc) and I think we need to show a bit more flexibility while fostering community participation as I (based on personal experience in previous ventures) strongly believe that a bug fixed jointly in such settings and merged right away draws more interest from attendees to the specific technology and goes to the heart of the community participation/collaboration (everyone present is part of that fix - a true community fix). After all, attendees of such event are the community and if there is a consensus among all, that should be enough for an implied +1. Don’t you agree?
Chers Oleg > On May 16, 2016, at 9:38 PM, Joe Witt <[email protected]> wrote: > > Tony: Good point and probably fair game. It would need to be really > urgent and really specific I think though. Otherwise no need to rush. > > Matt: Yeah that is a great idea. > > AdamL: Thanks for offering to setup a zoom. I'll try to do it and if > good will send details on meetup invite. If not I'll ping you. > > Thanks > Joe > > On Mon, May 16, 2016 at 9:15 PM, Tony Kurc <[email protected]> wrote: >> Joe - if a bug is discovered during the hackathon and patch developed, >> would this be an appropriate short turnaroundJIRA/patch/merge type >> situation? >> On May 16, 2016 5:31 PM, "Matt Burgess" <[email protected]> wrote: >> >>> One thing that could be done to enable demos while still having >>> PRs/patches go through the Apache process is to have the Organizer create a >>> hackathon branch off their fork, and merge in any patches/PRs that are >>> demo-able, then show the hackathon goodness at the end. Then the regular >>> process (Jira, review, etc) applies to the Apache branch(es) for inclusion >>> into the product. >>> >>> >>>> On May 16, 2016, at 5:03 PM, Joe Witt <[email protected]> wrote: >>>> >>>> Team, >>>> >>>> I wanted to shoot out a note to gather input on some rules of >>>> engagement so to speak for running a nifi hackathon/meetup. A few of >>>> us in the DC/MD area have one planned soon [1]. >>>> >>>> What I'd like to send out to the meetup group are some ground rules >>>> for how the meetup will operate. It is important because not everyone >>>> will be familiar with the Apache Way, it is being hosted in a vendor >>>> space, and because in general we want to make sure things like this >>>> can occur more in the future which means we want this to go well! >>>> >>>> Key points to make follow but if you have others please share: >>>> 1) Decisions cannot be made in such a setting. Rather the discussions >>>> that happen and the ideas and opinions formed in them need to be >>>> captured on the appropriate feature proposals, JIRAs, mailing-list >>>> discussions so others can participate. This includes feature ideas, >>>> code ideas, roadmap items, etc.. >>>> >>>> 2) We cannot just make up JIRAs, whip up some code, +1 and merge it >>>> during the meetup. If something is worthy of a RTC, which is >>>> basically all things code, then it needs to be given time for folks >>>> not sitting at the meetup to participate in - that is it should be >>>> treated like any other contribution. >>>> >>>> 3) Notes/summary of the meetup should occur and be made available to >>>> the community. >>>> >>>> [1] http://www.meetup.com/ApacheNiFi/events/230804255/ >>>> >>>> Thanks >>>> Joe >>> >
