[DISCUSS] nifi meetup/hackathon ground rules?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] nifi meetup/hackathon ground rules?

Joe Witt
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] nifi meetup/hackathon ground rules?

Matt Burgess
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] nifi meetup/hackathon ground rules?

trkurc
Administrator
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" <[hidden email]> 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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] nifi meetup/hackathon ground rules?

Joe Witt
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] nifi meetup/hackathon ground rules?

Oleg Zhurakousky
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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] nifi meetup/hackathon ground rules?

Joe Witt
"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...

Thanks
Joe


On Tue, May 17, 2016 at 9:02 AM, Oleg Zhurakousky
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>>>>
>>
>