nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <>
Subject Re: [DISCUSS] nifi meetup/hackathon ground rules?
Date Tue, 17 May 2016 13:18:13 GMT
"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?"

- Definitely share that view with a modifier that to be as inclusive
as we should we need to remember that not all the community will be
there.  For the type of items you note, which a reasonable person
might consider 'very obvious' I think it is fine to JIRA/PR/merge.
And of course someone could object post merge and that can be dealt
with too.  But for things which a reasonable person might object to or
prefer done another way we should allow time for that.  Basically
normal processes - file a JIRA, create a PR, can even have it +1 and
ready for merge but just hold off a bit to allow those not attending
to engage.

I'm glad we're having this thread for this very part of the discussion
because it gets to the heart of the apache way.  We need to be really
focused on getting it right and keeping it right because as the
community grows it becomes a genie you cannot easily put back in the
bottle.  If you look at other communities some have done this well and
some have not.  We definitely can...


On Tue, May 17, 2016 at 9:02 AM, Oleg Zhurakousky
<> wrote:
> 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 <> 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 <> 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" <> 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
>>>> 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 <> 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]
>>>>> Thanks
>>>>> Joe

View raw message