Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[Gurudatt Kulkarni]

I will take this up.

On Thu, Nov 21, 2019 at 8:05 AM vino yang  wrote:

> +1, we can try to use this feature.
>
> Best,
> Vino
>
> Vinoth Chandar  于2019年11月21日周四 上午8:28写道：
>
> > Github actions seems to be able to do this easily as well
> >
> >
> https://github.com/actions/starter-workflows/blob/master/automation/stale.yml
> >
> > On Mon, Nov 18, 2019 at 10:33 PM Gurudatt Kulkarni 
> > wrote:
> >
> > > > With templates, we can collect good information while people file the
> > > > issues..Not sure about permissions we have on JIRA to enable bots,
> but
> > > may
> > > > have more luck on github workflows doing these already?
> > > > Can we do templates/required fields with JIRAs as well?
> > >
> > >  Yes, it is very much possible to add custom fields, make a field
> > required
> > > in Jira, we have done it in our org. Not sure about a bot in jira.
> > >  Regarding the Github bot, I had particularly seen it here
> > > https://github.com/webpack/webpack/issues/9457#issuecomment-550546427.
> > >  This particular bot looks good https://probot.github.io/apps/stale/
> > >
> > >
> > > On Tue, Nov 19, 2019 at 7:41 AM vino yang 
> wrote:
> > >
> > > > Hi Gurudatt and Vinoth,
> > > >
> > > > Thanks for sharing your valuable opinion.
> > > >
> > > > Considering Hudi is still a growing project. I agree that it's better
> > to
> > > > keep Github's Issues tab as a way to discuss problems currently.
> > > >
> > > > +1 to introduce issue template and management bot.
> > > >
> > > > Best,
> > > > Vino
> > > >
> > > > Vinoth Chandar  于2019年11月19日周二 上午3:23写道：
> > > >
> > > > > If we decide to keep GitHub Issues, both great suggestions. We
> should
> > > > still
> > > > > debate if we keep GH issues. I just shared my opinion. :)
> > > > >
> > > > > With templates, we can collect good information while people file
> the
> > > > > issues..Not sure about permissions we have on JIRA to enable bots,
> > but
> > > > may
> > > > > have more luck on github workflows doing these already?
> > > > > Can we do templates/required fields with JIRAs as well?
> > >
> > > >
> > > > > On Mon, Nov 18, 2019 at 7:45 AM Gurudatt Kulkarni <
> > guruak...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Vinoth / Vino,
> > > > > >
> > > > > > Just adding my 2 cents to the discussion.  Yes, I agree that
> GitHub
> > > > > issues
> > > > > > are low friction and can be the first line of support. It will
> help
> > > in
> > > > > > keeping the JIRA clean.
> > > > > >
> > > > > > Potential solutions that I have come across in the community,
> > > > > > 1. Introduce an issue template.
> > > > > > 2. Add a bot that will automatically close issues that are
> inactive
> > > > for a
> > > > > > long time (Sample
> > > > > > <
> > > https://github.com/webpack/webpack/issues/9444#issuecomment-549823635
> > > > > >).
> > > > > >
> > > > > > The above solutions can help in keeping the GitHub issues
> > manageable
> > > > and
> > > > > > clean.
> > > > > > Regards,
> > > > > > Gurudatt
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Nov 18, 2019 at 8:38 PM Vinoth Chandar <
> vin...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > > @vinoyang. All valid points. I just have 1 argument (all others
> > you
> > > > are
> > > > > > > right and I have always known this tradeoff) for keeping Github
> > > > issues,
> > > > > > > when we are still growing the community and that is : it lets
> > > anyone
> > > > > > with a
> > > > > > > github id raise an issue without forcing to sign up for JIRA
> > > account.
> > > > > For
> > > > > > > large projects, yes I feel they can afford to have this
> > additional
> > > > step
> > > > > > > since they are much popular anyway :)
> > > > > > >
> > > > > > > A smaller subjective thing is. - I have liked that Github
> issues
> > > are
> > > > > just
> > > > > > > support issues and it declutters JIRA from having too many
> > support
> > > > > issues
> > > > > > > mixed with real code change/design JIRA. In other words, we
> have
> > > been
> > > > > > using
> > > > > > > issues as a way to groom the JIRAs. You are right that with
> > proper
> > > > > > > labelling, this can be done in JIRA as well.
> > > > > > >
> > > > > > > 1) We have actually done a very good job at this, until may be
> > last
> > > > > month
> > > > > > > and thats on me. I will clear up the issues.
> > > > > > > 2) We don't have any fancy dimensions of issues tracking.
> People
> > > just
> > > > > > paste
> > > > > > > stacktraces, configs, code snippets thats all. I actually
> > suggested
> > > > to
> > > > > > use
> > > > > > > gists in the official docs to avoid this. but users just find
> > > issues
> > > > > > easier
> > > > > > > I guess.
> > > > > > > 3) I agree.. It will get unmanageable eventually and thats a
> good
> > > > > problem
> > > > > > > to have. since it would mean we are really successful.
> > > > > > >
> > > > > > > May be make this change as we trend towards this path more or
> > favor
> > > > > ease
> > > > > > of

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[vino yang]

+1, we can try to use this feature.

Best,
Vino

Vinoth Chandar  于2019年11月21日周四 上午8:28写道：

> Github actions seems to be able to do this easily as well
>
> https://github.com/actions/starter-workflows/blob/master/automation/stale.yml
>
> On Mon, Nov 18, 2019 at 10:33 PM Gurudatt Kulkarni 
> wrote:
>
> > > With templates, we can collect good information while people file the
> > > issues..Not sure about permissions we have on JIRA to enable bots, but
> > may
> > > have more luck on github workflows doing these already?
> > > Can we do templates/required fields with JIRAs as well?
> >
> >  Yes, it is very much possible to add custom fields, make a field
> required
> > in Jira, we have done it in our org. Not sure about a bot in jira.
> >  Regarding the Github bot, I had particularly seen it here
> > https://github.com/webpack/webpack/issues/9457#issuecomment-550546427.
> >  This particular bot looks good https://probot.github.io/apps/stale/
> >
> >
> > On Tue, Nov 19, 2019 at 7:41 AM vino yang  wrote:
> >
> > > Hi Gurudatt and Vinoth,
> > >
> > > Thanks for sharing your valuable opinion.
> > >
> > > Considering Hudi is still a growing project. I agree that it's better
> to
> > > keep Github's Issues tab as a way to discuss problems currently.
> > >
> > > +1 to introduce issue template and management bot.
> > >
> > > Best,
> > > Vino
> > >
> > > Vinoth Chandar  于2019年11月19日周二 上午3:23写道：
> > >
> > > > If we decide to keep GitHub Issues, both great suggestions. We should
> > > still
> > > > debate if we keep GH issues. I just shared my opinion. :)
> > > >
> > > > With templates, we can collect good information while people file the
> > > > issues..Not sure about permissions we have on JIRA to enable bots,
> but
> > > may
> > > > have more luck on github workflows doing these already?
> > > > Can we do templates/required fields with JIRAs as well?
> >
> > >
> > > > On Mon, Nov 18, 2019 at 7:45 AM Gurudatt Kulkarni <
> guruak...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Vinoth / Vino,
> > > > >
> > > > > Just adding my 2 cents to the discussion.  Yes, I agree that GitHub
> > > > issues
> > > > > are low friction and can be the first line of support. It will help
> > in
> > > > > keeping the JIRA clean.
> > > > >
> > > > > Potential solutions that I have come across in the community,
> > > > > 1. Introduce an issue template.
> > > > > 2. Add a bot that will automatically close issues that are inactive
> > > for a
> > > > > long time (Sample
> > > > > <
> > https://github.com/webpack/webpack/issues/9444#issuecomment-549823635
> > > > >).
> > > > >
> > > > > The above solutions can help in keeping the GitHub issues
> manageable
> > > and
> > > > > clean.
> > > > > Regards,
> > > > > Gurudatt
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Nov 18, 2019 at 8:38 PM Vinoth Chandar 
> > > > wrote:
> > > > >
> > > > > > @vinoyang. All valid points. I just have 1 argument (all others
> you
> > > are
> > > > > > right and I have always known this tradeoff) for keeping Github
> > > issues,
> > > > > > when we are still growing the community and that is : it lets
> > anyone
> > > > > with a
> > > > > > github id raise an issue without forcing to sign up for JIRA
> > account.
> > > > For
> > > > > > large projects, yes I feel they can afford to have this
> additional
> > > step
> > > > > > since they are much popular anyway :)
> > > > > >
> > > > > > A smaller subjective thing is. - I have liked that Github issues
> > are
> > > > just
> > > > > > support issues and it declutters JIRA from having too many
> support
> > > > issues
> > > > > > mixed with real code change/design JIRA. In other words, we have
> > been
> > > > > using
> > > > > > issues as a way to groom the JIRAs. You are right that with
> proper
> > > > > > labelling, this can be done in JIRA as well.
> > > > > >
> > > > > > 1) We have actually done a very good job at this, until may be
> last
> > > > month
> > > > > > and thats on me. I will clear up the issues.
> > > > > > 2) We don't have any fancy dimensions of issues tracking. People
> > just
> > > > > paste
> > > > > > stacktraces, configs, code snippets thats all. I actually
> suggested
> > > to
> > > > > use
> > > > > > gists in the official docs to avoid this. but users just find
> > issues
> > > > > easier
> > > > > > I guess.
> > > > > > 3) I agree.. It will get unmanageable eventually and thats a good
> > > > problem
> > > > > > to have. since it would mean we are really successful.
> > > > > >
> > > > > > May be make this change as we trend towards this path more or
> favor
> > > > ease
> > > > > of
> > > > > > engagement in the short term, by keeping github issues?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Nov 15, 2019 at 7:01 PM vino yang  >
> > > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I am not a whimsy, a lot of Apache projects are doing this. Not
> >

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[Vinoth Chandar]

Github actions seems to be able to do this easily as well
https://github.com/actions/starter-workflows/blob/master/automation/stale.yml

On Mon, Nov 18, 2019 at 10:33 PM Gurudatt Kulkarni 
wrote:

> > With templates, we can collect good information while people file the
> > issues..Not sure about permissions we have on JIRA to enable bots, but
> may
> > have more luck on github workflows doing these already?
> > Can we do templates/required fields with JIRAs as well?
>
>  Yes, it is very much possible to add custom fields, make a field required
> in Jira, we have done it in our org. Not sure about a bot in jira.
>  Regarding the Github bot, I had particularly seen it here
> https://github.com/webpack/webpack/issues/9457#issuecomment-550546427.
>  This particular bot looks good https://probot.github.io/apps/stale/
>
>
> On Tue, Nov 19, 2019 at 7:41 AM vino yang  wrote:
>
> > Hi Gurudatt and Vinoth,
> >
> > Thanks for sharing your valuable opinion.
> >
> > Considering Hudi is still a growing project. I agree that it's better to
> > keep Github's Issues tab as a way to discuss problems currently.
> >
> > +1 to introduce issue template and management bot.
> >
> > Best,
> > Vino
> >
> > Vinoth Chandar  于2019年11月19日周二 上午3:23写道：
> >
> > > If we decide to keep GitHub Issues, both great suggestions. We should
> > still
> > > debate if we keep GH issues. I just shared my opinion. :)
> > >
> > > With templates, we can collect good information while people file the
> > > issues..Not sure about permissions we have on JIRA to enable bots, but
> > may
> > > have more luck on github workflows doing these already?
> > > Can we do templates/required fields with JIRAs as well?
>
> >
> > > On Mon, Nov 18, 2019 at 7:45 AM Gurudatt Kulkarni  >
> > > wrote:
> > >
> > > > Hi Vinoth / Vino,
> > > >
> > > > Just adding my 2 cents to the discussion.  Yes, I agree that GitHub
> > > issues
> > > > are low friction and can be the first line of support. It will help
> in
> > > > keeping the JIRA clean.
> > > >
> > > > Potential solutions that I have come across in the community,
> > > > 1. Introduce an issue template.
> > > > 2. Add a bot that will automatically close issues that are inactive
> > for a
> > > > long time (Sample
> > > > <
> https://github.com/webpack/webpack/issues/9444#issuecomment-549823635
> > > >).
> > > >
> > > > The above solutions can help in keeping the GitHub issues manageable
> > and
> > > > clean.
> > > > Regards,
> > > > Gurudatt
> > > >
> > > >
> > > >
> > > > On Mon, Nov 18, 2019 at 8:38 PM Vinoth Chandar 
> > > wrote:
> > > >
> > > > > @vinoyang. All valid points. I just have 1 argument (all others you
> > are
> > > > > right and I have always known this tradeoff) for keeping Github
> > issues,
> > > > > when we are still growing the community and that is : it lets
> anyone
> > > > with a
> > > > > github id raise an issue without forcing to sign up for JIRA
> account.
> > > For
> > > > > large projects, yes I feel they can afford to have this additional
> > step
> > > > > since they are much popular anyway :)
> > > > >
> > > > > A smaller subjective thing is. - I have liked that Github issues
> are
> > > just
> > > > > support issues and it declutters JIRA from having too many support
> > > issues
> > > > > mixed with real code change/design JIRA. In other words, we have
> been
> > > > using
> > > > > issues as a way to groom the JIRAs. You are right that with proper
> > > > > labelling, this can be done in JIRA as well.
> > > > >
> > > > > 1) We have actually done a very good job at this, until may be last
> > > month
> > > > > and thats on me. I will clear up the issues.
> > > > > 2) We don't have any fancy dimensions of issues tracking. People
> just
> > > > paste
> > > > > stacktraces, configs, code snippets thats all. I actually suggested
> > to
> > > > use
> > > > > gists in the official docs to avoid this. but users just find
> issues
> > > > easier
> > > > > I guess.
> > > > > 3) I agree.. It will get unmanageable eventually and thats a good
> > > problem
> > > > > to have. since it would mean we are really successful.
> > > > >
> > > > > May be make this change as we trend towards this path more or favor
> > > ease
> > > > of
> > > > > engagement in the short term, by keeping github issues?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Nov 15, 2019 at 7:01 PM vino yang 
> > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I am not a whimsy, a lot of Apache projects are doing this. Not
> > just
> > > > > Flink,
> > > > > > the project list is very long, including Spark, Kafka, Kylin,
> > > Calcite,
> > > > > > Hadoop, storm...
> > > > > >
> > > > > > It's no accident that so many projects do this. As the project
> > grows
> > > > > > rapidly, we will find that two ways that report issues will
> become
> > > very
> > > > > > difficult to maintain, which is almost predictable.
> > > > > >
> > > > > > I ha

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[Gurudatt Kulkarni]

> With templates, we can collect good information while people file the
> issues..Not sure about permissions we have on JIRA to enable bots, but may
> have more luck on github workflows doing these already?
> Can we do templates/required fields with JIRAs as well?

 Yes, it is very much possible to add custom fields, make a field required
in Jira, we have done it in our org. Not sure about a bot in jira.
 Regarding the Github bot, I had particularly seen it here
https://github.com/webpack/webpack/issues/9457#issuecomment-550546427.
 This particular bot looks good https://probot.github.io/apps/stale/


On Tue, Nov 19, 2019 at 7:41 AM vino yang  wrote:

> Hi Gurudatt and Vinoth,
>
> Thanks for sharing your valuable opinion.
>
> Considering Hudi is still a growing project. I agree that it's better to
> keep Github's Issues tab as a way to discuss problems currently.
>
> +1 to introduce issue template and management bot.
>
> Best,
> Vino
>
> Vinoth Chandar  于2019年11月19日周二 上午3:23写道：
>
> > If we decide to keep GitHub Issues, both great suggestions. We should
> still
> > debate if we keep GH issues. I just shared my opinion. :)
> >
> > With templates, we can collect good information while people file the
> > issues..Not sure about permissions we have on JIRA to enable bots, but
> may
> > have more luck on github workflows doing these already?
> > Can we do templates/required fields with JIRAs as well?

>
> > On Mon, Nov 18, 2019 at 7:45 AM Gurudatt Kulkarni 
> > wrote:
> >
> > > Hi Vinoth / Vino,
> > >
> > > Just adding my 2 cents to the discussion.  Yes, I agree that GitHub
> > issues
> > > are low friction and can be the first line of support. It will help in
> > > keeping the JIRA clean.
> > >
> > > Potential solutions that I have come across in the community,
> > > 1. Introduce an issue template.
> > > 2. Add a bot that will automatically close issues that are inactive
> for a
> > > long time (Sample
> > >  > >).
> > >
> > > The above solutions can help in keeping the GitHub issues manageable
> and
> > > clean.
> > > Regards,
> > > Gurudatt
> > >
> > >
> > >
> > > On Mon, Nov 18, 2019 at 8:38 PM Vinoth Chandar 
> > wrote:
> > >
> > > > @vinoyang. All valid points. I just have 1 argument (all others you
> are
> > > > right and I have always known this tradeoff) for keeping Github
> issues,
> > > > when we are still growing the community and that is : it lets anyone
> > > with a
> > > > github id raise an issue without forcing to sign up for JIRA account.
> > For
> > > > large projects, yes I feel they can afford to have this additional
> step
> > > > since they are much popular anyway :)
> > > >
> > > > A smaller subjective thing is. - I have liked that Github issues are
> > just
> > > > support issues and it declutters JIRA from having too many support
> > issues
> > > > mixed with real code change/design JIRA. In other words, we have been
> > > using
> > > > issues as a way to groom the JIRAs. You are right that with proper
> > > > labelling, this can be done in JIRA as well.
> > > >
> > > > 1) We have actually done a very good job at this, until may be last
> > month
> > > > and thats on me. I will clear up the issues.
> > > > 2) We don't have any fancy dimensions of issues tracking. People just
> > > paste
> > > > stacktraces, configs, code snippets thats all. I actually suggested
> to
> > > use
> > > > gists in the official docs to avoid this. but users just find issues
> > > easier
> > > > I guess.
> > > > 3) I agree.. It will get unmanageable eventually and thats a good
> > problem
> > > > to have. since it would mean we are really successful.
> > > >
> > > > May be make this change as we trend towards this path more or favor
> > ease
> > > of
> > > > engagement in the short term, by keeping github issues?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Nov 15, 2019 at 7:01 PM vino yang 
> > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I am not a whimsy, a lot of Apache projects are doing this. Not
> just
> > > > Flink,
> > > > > the project list is very long, including Spark, Kafka, Kylin,
> > Calcite,
> > > > > Hadoop, storm...
> > > > >
> > > > > It's no accident that so many projects do this. As the project
> grows
> > > > > rapidly, we will find that two ways that report issues will become
> > very
> > > > > difficult to maintain, which is almost predictable.
> > > > >
> > > > > I have several concerns:
> > > > >
> > > > > 1) If we open the Github Issues portal, who is responsible for
> > > > > synchronizing real issues to JIRA?
> > > > >
> > > > > 2) Who maintains the various dimensions of the issue, there are
> many
> > > > types
> > > > > of issues, including discussions, ideas, problem reports,
> > suggestions,
> > > in
> > > > > order to distinguish them, it is estimated that we may need to
> > > introduce
> > > > > tags, while on JIRA we have maintained "Comp

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[vino yang]

Hi Gurudatt and Vinoth,

Thanks for sharing your valuable opinion.

Considering Hudi is still a growing project. I agree that it's better to
keep Github's Issues tab as a way to discuss problems currently.

+1 to introduce issue template and management bot.

Best,
Vino

Vinoth Chandar  于2019年11月19日周二 上午3:23写道：

> If we decide to keep GitHub Issues, both great suggestions. We should still
> debate if we keep GH issues. I just shared my opinion. :)
>
> With templates, we can collect good information while people file the
> issues..Not sure about permissions we have on JIRA to enable bots, but may
> have more luck on github workflows doing these already?
> Can we do templates/required fields with JIRAs as well?
>
> On Mon, Nov 18, 2019 at 7:45 AM Gurudatt Kulkarni 
> wrote:
>
> > Hi Vinoth / Vino,
> >
> > Just adding my 2 cents to the discussion.  Yes, I agree that GitHub
> issues
> > are low friction and can be the first line of support. It will help in
> > keeping the JIRA clean.
> >
> > Potential solutions that I have come across in the community,
> > 1. Introduce an issue template.
> > 2. Add a bot that will automatically close issues that are inactive for a
> > long time (Sample
> >  >).
> >
> > The above solutions can help in keeping the GitHub issues manageable and
> > clean.
> > Regards,
> > Gurudatt
> >
> >
> >
> > On Mon, Nov 18, 2019 at 8:38 PM Vinoth Chandar 
> wrote:
> >
> > > @vinoyang. All valid points. I just have 1 argument (all others you are
> > > right and I have always known this tradeoff) for keeping Github issues,
> > > when we are still growing the community and that is : it lets anyone
> > with a
> > > github id raise an issue without forcing to sign up for JIRA account.
> For
> > > large projects, yes I feel they can afford to have this additional step
> > > since they are much popular anyway :)
> > >
> > > A smaller subjective thing is. - I have liked that Github issues are
> just
> > > support issues and it declutters JIRA from having too many support
> issues
> > > mixed with real code change/design JIRA. In other words, we have been
> > using
> > > issues as a way to groom the JIRAs. You are right that with proper
> > > labelling, this can be done in JIRA as well.
> > >
> > > 1) We have actually done a very good job at this, until may be last
> month
> > > and thats on me. I will clear up the issues.
> > > 2) We don't have any fancy dimensions of issues tracking. People just
> > paste
> > > stacktraces, configs, code snippets thats all. I actually suggested to
> > use
> > > gists in the official docs to avoid this. but users just find issues
> > easier
> > > I guess.
> > > 3) I agree.. It will get unmanageable eventually and thats a good
> problem
> > > to have. since it would mean we are really successful.
> > >
> > > May be make this change as we trend towards this path more or favor
> ease
> > of
> > > engagement in the short term, by keeping github issues?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Nov 15, 2019 at 7:01 PM vino yang 
> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I am not a whimsy, a lot of Apache projects are doing this. Not just
> > > Flink,
> > > > the project list is very long, including Spark, Kafka, Kylin,
> Calcite,
> > > > Hadoop, storm...
> > > >
> > > > It's no accident that so many projects do this. As the project grows
> > > > rapidly, we will find that two ways that report issues will become
> very
> > > > difficult to maintain, which is almost predictable.
> > > >
> > > > I have several concerns:
> > > >
> > > > 1) If we open the Github Issues portal, who is responsible for
> > > > synchronizing real issues to JIRA?
> > > >
> > > > 2) Who maintains the various dimensions of the issue, there are many
> > > types
> > > > of issues, including discussions, ideas, problem reports,
> suggestions,
> > in
> > > > order to distinguish them, it is estimated that we may need to
> > introduce
> > > > tags, while on JIRA we have maintained "Component" and "Type", and
> the
> > > > version, users will find the "Affect version" and "Fix version" of
> the
> > > > issue.
> > > >
> > > > 3) As the project grows rapidly, the issue list of several pages may
> > give
> > > > the user the impression that "this project has a lot of problems and
> > the
> > > > response is very slow"?
> > > >
> > > > Forcing users to turn to JIRA and using it as the only entry point to
> > ask
> > > > and discuss specific issues is a very good habit, which brings a
> better
> > > > experience for those who trace historical issues.
> > > >
> > > > I know that everyone's focus is on Github's Issues can give users a
> > good
> > > > way to discuss issues and paste code, but JIRA also has this ability.
> > We
> > > > can't constrain user to create the issue which just for discussion
> > rather
> > > > than a bug or other.
> > > >
> > > > Just a personal thought. Maybe we can keep it 

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[Vinoth Chandar]

If we decide to keep GitHub Issues, both great suggestions. We should still
debate if we keep GH issues. I just shared my opinion. :)

With templates, we can collect good information while people file the
issues..Not sure about permissions we have on JIRA to enable bots, but may
have more luck on github workflows doing these already?
Can we do templates/required fields with JIRAs as well?

On Mon, Nov 18, 2019 at 7:45 AM Gurudatt Kulkarni 
wrote:

> Hi Vinoth / Vino,
>
> Just adding my 2 cents to the discussion.  Yes, I agree that GitHub issues
> are low friction and can be the first line of support. It will help in
> keeping the JIRA clean.
>
> Potential solutions that I have come across in the community,
> 1. Introduce an issue template.
> 2. Add a bot that will automatically close issues that are inactive for a
> long time (Sample
> ).
>
> The above solutions can help in keeping the GitHub issues manageable and
> clean.
> Regards,
> Gurudatt
>
>
>
> On Mon, Nov 18, 2019 at 8:38 PM Vinoth Chandar  wrote:
>
> > @vinoyang. All valid points. I just have 1 argument (all others you are
> > right and I have always known this tradeoff) for keeping Github issues,
> > when we are still growing the community and that is : it lets anyone
> with a
> > github id raise an issue without forcing to sign up for JIRA account. For
> > large projects, yes I feel they can afford to have this additional step
> > since they are much popular anyway :)
> >
> > A smaller subjective thing is. - I have liked that Github issues are just
> > support issues and it declutters JIRA from having too many support issues
> > mixed with real code change/design JIRA. In other words, we have been
> using
> > issues as a way to groom the JIRAs. You are right that with proper
> > labelling, this can be done in JIRA as well.
> >
> > 1) We have actually done a very good job at this, until may be last month
> > and thats on me. I will clear up the issues.
> > 2) We don't have any fancy dimensions of issues tracking. People just
> paste
> > stacktraces, configs, code snippets thats all. I actually suggested to
> use
> > gists in the official docs to avoid this. but users just find issues
> easier
> > I guess.
> > 3) I agree.. It will get unmanageable eventually and thats a good problem
> > to have. since it would mean we are really successful.
> >
> > May be make this change as we trend towards this path more or favor ease
> of
> > engagement in the short term, by keeping github issues?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Nov 15, 2019 at 7:01 PM vino yang  wrote:
> >
> > > Hi all,
> > >
> > > I am not a whimsy, a lot of Apache projects are doing this. Not just
> > Flink,
> > > the project list is very long, including Spark, Kafka, Kylin, Calcite,
> > > Hadoop, storm...
> > >
> > > It's no accident that so many projects do this. As the project grows
> > > rapidly, we will find that two ways that report issues will become very
> > > difficult to maintain, which is almost predictable.
> > >
> > > I have several concerns:
> > >
> > > 1) If we open the Github Issues portal, who is responsible for
> > > synchronizing real issues to JIRA?
> > >
> > > 2) Who maintains the various dimensions of the issue, there are many
> > types
> > > of issues, including discussions, ideas, problem reports, suggestions,
> in
> > > order to distinguish them, it is estimated that we may need to
> introduce
> > > tags, while on JIRA we have maintained "Component" and "Type", and the
> > > version, users will find the "Affect version" and "Fix version" of the
> > > issue.
> > >
> > > 3) As the project grows rapidly, the issue list of several pages may
> give
> > > the user the impression that "this project has a lot of problems and
> the
> > > response is very slow"?
> > >
> > > Forcing users to turn to JIRA and using it as the only entry point to
> ask
> > > and discuss specific issues is a very good habit, which brings a better
> > > experience for those who trace historical issues.
> > >
> > > I know that everyone's focus is on Github's Issues can give users a
> good
> > > way to discuss issues and paste code, but JIRA also has this ability.
> We
> > > can't constrain user to create the issue which just for discussion
> rather
> > > than a bug or other.
> > >
> > > Just a personal thought. Maybe we can keep it at the beginning of the
> > > project, but in the future, maybe we will have to close.
> > >
> > > Best,
> > > Vino
> > >
> > > leesf  于2019年11月16日周六 上午7:51写道：
> > >
> > > > Hi vino,
> > > >
> > > > Thanks for bringing up the discussion.
> > > >
> > > > IMHO, the issues and jira are not opposite and we could use them both
> > for
> > > > their advantages. Such as for some simple questions which is no need
> to
> > > > open a jira or send a mail [1], users could get quick response from
> > > others
> > > > via issues and then close it.
> > > >
> > > > But as you can see, current 

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[Gurudatt Kulkarni]

Hi Vinoth / Vino,

Just adding my 2 cents to the discussion.  Yes, I agree that GitHub issues
are low friction and can be the first line of support. It will help in
keeping the JIRA clean.

Potential solutions that I have come across in the community,
1. Introduce an issue template.
2. Add a bot that will automatically close issues that are inactive for a
long time (Sample
).

The above solutions can help in keeping the GitHub issues manageable and
clean.
Regards,
Gurudatt



On Mon, Nov 18, 2019 at 8:38 PM Vinoth Chandar  wrote:

> @vinoyang. All valid points. I just have 1 argument (all others you are
> right and I have always known this tradeoff) for keeping Github issues,
> when we are still growing the community and that is : it lets anyone with a
> github id raise an issue without forcing to sign up for JIRA account. For
> large projects, yes I feel they can afford to have this additional step
> since they are much popular anyway :)
>
> A smaller subjective thing is. - I have liked that Github issues are just
> support issues and it declutters JIRA from having too many support issues
> mixed with real code change/design JIRA. In other words, we have been using
> issues as a way to groom the JIRAs. You are right that with proper
> labelling, this can be done in JIRA as well.
>
> 1) We have actually done a very good job at this, until may be last month
> and thats on me. I will clear up the issues.
> 2) We don't have any fancy dimensions of issues tracking. People just paste
> stacktraces, configs, code snippets thats all. I actually suggested to use
> gists in the official docs to avoid this. but users just find issues easier
> I guess.
> 3) I agree.. It will get unmanageable eventually and thats a good problem
> to have. since it would mean we are really successful.
>
> May be make this change as we trend towards this path more or favor ease of
> engagement in the short term, by keeping github issues?
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Nov 15, 2019 at 7:01 PM vino yang  wrote:
>
> > Hi all,
> >
> > I am not a whimsy, a lot of Apache projects are doing this. Not just
> Flink,
> > the project list is very long, including Spark, Kafka, Kylin, Calcite,
> > Hadoop, storm...
> >
> > It's no accident that so many projects do this. As the project grows
> > rapidly, we will find that two ways that report issues will become very
> > difficult to maintain, which is almost predictable.
> >
> > I have several concerns:
> >
> > 1) If we open the Github Issues portal, who is responsible for
> > synchronizing real issues to JIRA?
> >
> > 2) Who maintains the various dimensions of the issue, there are many
> types
> > of issues, including discussions, ideas, problem reports, suggestions, in
> > order to distinguish them, it is estimated that we may need to introduce
> > tags, while on JIRA we have maintained "Component" and "Type", and the
> > version, users will find the "Affect version" and "Fix version" of the
> > issue.
> >
> > 3) As the project grows rapidly, the issue list of several pages may give
> > the user the impression that "this project has a lot of problems and the
> > response is very slow"?
> >
> > Forcing users to turn to JIRA and using it as the only entry point to ask
> > and discuss specific issues is a very good habit, which brings a better
> > experience for those who trace historical issues.
> >
> > I know that everyone's focus is on Github's Issues can give users a good
> > way to discuss issues and paste code, but JIRA also has this ability. We
> > can't constrain user to create the issue which just for discussion rather
> > than a bug or other.
> >
> > Just a personal thought. Maybe we can keep it at the beginning of the
> > project, but in the future, maybe we will have to close.
> >
> > Best,
> > Vino
> >
> > leesf  于2019年11月16日周六 上午7:51写道：
> >
> > > Hi vino,
> > >
> > > Thanks for bringing up the discussion.
> > >
> > > IMHO, the issues and jira are not opposite and we could use them both
> for
> > > their advantages. Such as for some simple questions which is no need to
> > > open a jira or send a mail [1], users could get quick response from
> > others
> > > via issues and then close it.
> > >
> > > But as you can see, current users are more likely to create issues
> > through
> > > issues instead of jira, and then the issues will be migrated to jira if
> > > they are indeed issues after discussion, which need extra work.
> > >
> > > So keep the issues tab open may be more convenient for common users
> > while a
> > > little more expensive to maintain two entries.
> > >
> > > Open to hearing other thoughts.
> > >
> > > Best,
> > > Leesf
> > >
> > >
> > > [1] https://github.com/apache/incubator-hudi/issues/1017
> > >
> > > Vinoth Chandar  于2019年11月15日周五 下午8:28写道：
> > >
> > > > Hi Vino,
> > > >
> > > > To echo what Nishith was saying, issues is only being used currently
> > for
> > > > support i.e looking at stack traces

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[Vinoth Chandar]

@vinoyang. All valid points. I just have 1 argument (all others you are
right and I have always known this tradeoff) for keeping Github issues,
when we are still growing the community and that is : it lets anyone with a
github id raise an issue without forcing to sign up for JIRA account. For
large projects, yes I feel they can afford to have this additional step
since they are much popular anyway :)

A smaller subjective thing is. - I have liked that Github issues are just
support issues and it declutters JIRA from having too many support issues
mixed with real code change/design JIRA. In other words, we have been using
issues as a way to groom the JIRAs. You are right that with proper
labelling, this can be done in JIRA as well.

1) We have actually done a very good job at this, until may be last month
and thats on me. I will clear up the issues.
2) We don't have any fancy dimensions of issues tracking. People just paste
stacktraces, configs, code snippets thats all. I actually suggested to use
gists in the official docs to avoid this. but users just find issues easier
I guess.
3) I agree.. It will get unmanageable eventually and thats a good problem
to have. since it would mean we are really successful.

May be make this change as we trend towards this path more or favor ease of
engagement in the short term, by keeping github issues?











On Fri, Nov 15, 2019 at 7:01 PM vino yang  wrote:

> Hi all,
>
> I am not a whimsy, a lot of Apache projects are doing this. Not just Flink,
> the project list is very long, including Spark, Kafka, Kylin, Calcite,
> Hadoop, storm...
>
> It's no accident that so many projects do this. As the project grows
> rapidly, we will find that two ways that report issues will become very
> difficult to maintain, which is almost predictable.
>
> I have several concerns:
>
> 1) If we open the Github Issues portal, who is responsible for
> synchronizing real issues to JIRA?
>
> 2) Who maintains the various dimensions of the issue, there are many types
> of issues, including discussions, ideas, problem reports, suggestions, in
> order to distinguish them, it is estimated that we may need to introduce
> tags, while on JIRA we have maintained "Component" and "Type", and the
> version, users will find the "Affect version" and "Fix version" of the
> issue.
>
> 3) As the project grows rapidly, the issue list of several pages may give
> the user the impression that "this project has a lot of problems and the
> response is very slow"?
>
> Forcing users to turn to JIRA and using it as the only entry point to ask
> and discuss specific issues is a very good habit, which brings a better
> experience for those who trace historical issues.
>
> I know that everyone's focus is on Github's Issues can give users a good
> way to discuss issues and paste code, but JIRA also has this ability. We
> can't constrain user to create the issue which just for discussion rather
> than a bug or other.
>
> Just a personal thought. Maybe we can keep it at the beginning of the
> project, but in the future, maybe we will have to close.
>
> Best,
> Vino
>
> leesf  于2019年11月16日周六 上午7:51写道：
>
> > Hi vino,
> >
> > Thanks for bringing up the discussion.
> >
> > IMHO, the issues and jira are not opposite and we could use them both for
> > their advantages. Such as for some simple questions which is no need to
> > open a jira or send a mail [1], users could get quick response from
> others
> > via issues and then close it.
> >
> > But as you can see, current users are more likely to create issues
> through
> > issues instead of jira, and then the issues will be migrated to jira if
> > they are indeed issues after discussion, which need extra work.
> >
> > So keep the issues tab open may be more convenient for common users
> while a
> > little more expensive to maintain two entries.
> >
> > Open to hearing other thoughts.
> >
> > Best,
> > Leesf
> >
> >
> > [1] https://github.com/apache/incubator-hudi/issues/1017
> >
> > Vinoth Chandar  于2019年11月15日周五 下午8:28写道：
> >
> > > Hi Vino,
> > >
> > > To echo what Nishith was saying, issues is only being used currently
> for
> > > support i.e looking at stack traces for failures, user errors. Any real
> > > work resulting from that always gets a JIRA.
> > >
> > > I mulled the same thing - disabling issues - a while back. The value I
> > see
> > > it adding is
> > >
> > > - if you already have a Github account, you can quickly get help
> > > - mailing list is not great for pasting/reading code. It helps with
> that
> > >
> > > In other words, it helps keep our JIRAs high quality and low noise.
> > >
> > > Just adding one more perspective. I am coming from “if its not broken,
> > dont
> > > fix it yet” angle.
> > >
> > > Open to hearing everyones thoughts
> > >
> > >
> > > Thanks
> > > Vinoth
> > >
> > > On Fri, Nov 15, 2019 at 3:54 AM Nishith  wrote:
> > >
> > > > Hey Vino,
> > > >
> > > > Earlier this year, we actually migrated all issues from GitHub to
> Jira
> > > and
> > > 

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[vino yang]

Hi all,

I am not a whimsy, a lot of Apache projects are doing this. Not just Flink,
the project list is very long, including Spark, Kafka, Kylin, Calcite,
Hadoop, storm...

It's no accident that so many projects do this. As the project grows
rapidly, we will find that two ways that report issues will become very
difficult to maintain, which is almost predictable.

I have several concerns:

1) If we open the Github Issues portal, who is responsible for
synchronizing real issues to JIRA?

2) Who maintains the various dimensions of the issue, there are many types
of issues, including discussions, ideas, problem reports, suggestions, in
order to distinguish them, it is estimated that we may need to introduce
tags, while on JIRA we have maintained "Component" and "Type", and the
version, users will find the "Affect version" and "Fix version" of the
issue.

3) As the project grows rapidly, the issue list of several pages may give
the user the impression that "this project has a lot of problems and the
response is very slow"?

Forcing users to turn to JIRA and using it as the only entry point to ask
and discuss specific issues is a very good habit, which brings a better
experience for those who trace historical issues.

I know that everyone's focus is on Github's Issues can give users a good
way to discuss issues and paste code, but JIRA also has this ability. We
can't constrain user to create the issue which just for discussion rather
than a bug or other.

Just a personal thought. Maybe we can keep it at the beginning of the
project, but in the future, maybe we will have to close.

Best,
Vino

leesf  于2019年11月16日周六 上午7:51写道：

> Hi vino,
>
> Thanks for bringing up the discussion.
>
> IMHO, the issues and jira are not opposite and we could use them both for
> their advantages. Such as for some simple questions which is no need to
> open a jira or send a mail [1], users could get quick response from others
> via issues and then close it.
>
> But as you can see, current users are more likely to create issues  through
> issues instead of jira, and then the issues will be migrated to jira if
> they are indeed issues after discussion, which need extra work.
>
> So keep the issues tab open may be more convenient for common users while a
> little more expensive to maintain two entries.
>
> Open to hearing other thoughts.
>
> Best,
> Leesf
>
>
> [1] https://github.com/apache/incubator-hudi/issues/1017
>
> Vinoth Chandar  于2019年11月15日周五 下午8:28写道：
>
> > Hi Vino,
> >
> > To echo what Nishith was saying, issues is only being used currently for
> > support i.e looking at stack traces for failures, user errors. Any real
> > work resulting from that always gets a JIRA.
> >
> > I mulled the same thing - disabling issues - a while back. The value I
> see
> > it adding is
> >
> > - if you already have a Github account, you can quickly get help
> > - mailing list is not great for pasting/reading code. It helps with that
> >
> > In other words, it helps keep our JIRAs high quality and low noise.
> >
> > Just adding one more perspective. I am coming from “if its not broken,
> dont
> > fix it yet” angle.
> >
> > Open to hearing everyones thoughts
> >
> >
> > Thanks
> > Vinoth
> >
> > On Fri, Nov 15, 2019 at 3:54 AM Nishith  wrote:
> >
> > > Hey Vino,
> > >
> > > Earlier this year, we actually migrated all issues from GitHub to Jira
> > and
> > > that’s the recommended route to discuss issues (besides the mailing
> > thread)
> > > The remaining issues are either new (folks might open an issue
> > regardless)
> > > and we help navigate those folks to open JIRA’s or there are existing
> > ones
> > > with a long chain of discussions which should be ideally closed.
> > > I think we can do one more round of clean up on the issues to see if
> > there
> > > are any non-active tickets.
> > >
> > > -Nishith
> > >
> > > Sent from my iPhone
> > >
> > > > On Nov 15, 2019, at 5:12 PM, vino yang 
> wrote:
> > > >
> > > > Hi guys,
> > > >
> > > > Since we use JIRA to manage issues like the other Apache projects.
> > IMHO,
> > > we
> > > > can stop opening Github's Issues tab [1] to unify issues and reduce
> > > > maintenance costs.
> > > >
> > > > This is not the first case, and the Flink community uses this
> > > approach.[2]
> > > >
> > > > Of course, if this proposal is adopted, we may need to migrate the
> > > existing
> > > > issues on Github to JIRA before we can hide it.
> > > >
> > > > This is just a proposal and I want to hear from the community.
> > > >
> > > > Best,
> > > > Vino
> > > >
> > > > [1]: https://github.com/apache/incubator-hudi/issues
> > > > [2]: https://github.com/apache/flink
> > >
> >
>

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[leesf]

Hi vino,

Thanks for bringing up the discussion.

IMHO, the issues and jira are not opposite and we could use them both for
their advantages. Such as for some simple questions which is no need to
open a jira or send a mail [1], users could get quick response from others
via issues and then close it.

But as you can see, current users are more likely to create issues  through
issues instead of jira, and then the issues will be migrated to jira if
they are indeed issues after discussion, which need extra work.

So keep the issues tab open may be more convenient for common users while a
little more expensive to maintain two entries.

Open to hearing other thoughts.

Best,
Leesf


[1] https://github.com/apache/incubator-hudi/issues/1017

Vinoth Chandar  于2019年11月15日周五 下午8:28写道：

> Hi Vino,
>
> To echo what Nishith was saying, issues is only being used currently for
> support i.e looking at stack traces for failures, user errors. Any real
> work resulting from that always gets a JIRA.
>
> I mulled the same thing - disabling issues - a while back. The value I see
> it adding is
>
> - if you already have a Github account, you can quickly get help
> - mailing list is not great for pasting/reading code. It helps with that
>
> In other words, it helps keep our JIRAs high quality and low noise.
>
> Just adding one more perspective. I am coming from “if its not broken, dont
> fix it yet” angle.
>
> Open to hearing everyones thoughts
>
>
> Thanks
> Vinoth
>
> On Fri, Nov 15, 2019 at 3:54 AM Nishith  wrote:
>
> > Hey Vino,
> >
> > Earlier this year, we actually migrated all issues from GitHub to Jira
> and
> > that’s the recommended route to discuss issues (besides the mailing
> thread)
> > The remaining issues are either new (folks might open an issue
> regardless)
> > and we help navigate those folks to open JIRA’s or there are existing
> ones
> > with a long chain of discussions which should be ideally closed.
> > I think we can do one more round of clean up on the issues to see if
> there
> > are any non-active tickets.
> >
> > -Nishith
> >
> > Sent from my iPhone
> >
> > > On Nov 15, 2019, at 5:12 PM, vino yang  wrote:
> > >
> > > Hi guys,
> > >
> > > Since we use JIRA to manage issues like the other Apache projects.
> IMHO,
> > we
> > > can stop opening Github's Issues tab [1] to unify issues and reduce
> > > maintenance costs.
> > >
> > > This is not the first case, and the Flink community uses this
> > approach.[2]
> > >
> > > Of course, if this proposal is adopted, we may need to migrate the
> > existing
> > > issues on Github to JIRA before we can hide it.
> > >
> > > This is just a proposal and I want to hear from the community.
> > >
> > > Best,
> > > Vino
> > >
> > > [1]: https://github.com/apache/incubator-hudi/issues
> > > [2]: https://github.com/apache/flink
> >
>

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[Vinoth Chandar]

Hi Vino,

To echo what Nishith was saying, issues is only being used currently for
support i.e looking at stack traces for failures, user errors. Any real
work resulting from that always gets a JIRA.

I mulled the same thing - disabling issues - a while back. The value I see
it adding is

- if you already have a Github account, you can quickly get help
- mailing list is not great for pasting/reading code. It helps with that

In other words, it helps keep our JIRAs high quality and low noise.

Just adding one more perspective. I am coming from “if its not broken, dont
fix it yet” angle.

Open to hearing everyones thoughts


Thanks
Vinoth

On Fri, Nov 15, 2019 at 3:54 AM Nishith  wrote:

> Hey Vino,
>
> Earlier this year, we actually migrated all issues from GitHub to Jira and
> that’s the recommended route to discuss issues (besides the mailing thread)
> The remaining issues are either new (folks might open an issue regardless)
> and we help navigate those folks to open JIRA’s or there are existing ones
> with a long chain of discussions which should be ideally closed.
> I think we can do one more round of clean up on the issues to see if there
> are any non-active tickets.
>
> -Nishith
>
> Sent from my iPhone
>
> > On Nov 15, 2019, at 5:12 PM, vino yang  wrote:
> >
> > Hi guys,
> >
> > Since we use JIRA to manage issues like the other Apache projects. IMHO,
> we
> > can stop opening Github's Issues tab [1] to unify issues and reduce
> > maintenance costs.
> >
> > This is not the first case, and the Flink community uses this
> approach.[2]
> >
> > Of course, if this proposal is adopted, we may need to migrate the
> existing
> > issues on Github to JIRA before we can hide it.
> >
> > This is just a proposal and I want to hear from the community.
> >
> > Best,
> > Vino
> >
> > [1]: https://github.com/apache/incubator-hudi/issues
> > [2]: https://github.com/apache/flink
>

Re: [DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[Nishith]

Hey Vino,

Earlier this year, we actually migrated all issues from GitHub to Jira and 
that’s the recommended route to discuss issues (besides the mailing thread) The 
remaining issues are either new (folks might open an issue regardless) and we 
help navigate those folks to open JIRA’s or there are existing ones with a long 
chain of discussions which should be ideally closed. 
I think we can do one more round of clean up on the issues to see if there are 
any non-active tickets.

-Nishith

Sent from my iPhone

> On Nov 15, 2019, at 5:12 PM, vino yang  wrote:
> 
> Hi guys,
> 
> Since we use JIRA to manage issues like the other Apache projects. IMHO, we
> can stop opening Github's Issues tab [1] to unify issues and reduce
> maintenance costs.
> 
> This is not the first case, and the Flink community uses this approach.[2]
> 
> Of course, if this proposal is adopted, we may need to migrate the existing
> issues on Github to JIRA before we can hide it.
> 
> This is just a proposal and I want to hear from the community.
> 
> Best,
> Vino
> 
> [1]: https://github.com/apache/incubator-hudi/issues
> [2]: https://github.com/apache/flink

[DISCUSS] Hide Github issues tab and Unified management of issues in JIRA

[vino yang]

Hi guys,

Since we use JIRA to manage issues like the other Apache projects. IMHO, we
can stop opening Github's Issues tab [1] to unify issues and reduce
maintenance costs.

This is not the first case, and the Flink community uses this approach.[2]

Of course, if this proposal is adopted, we may need to migrate the existing
issues on Github to JIRA before we can hide it.

This is just a proposal and I want to hear from the community.

Best,
Vino

[1]: https://github.com/apache/incubator-hudi/issues
[2]: https://github.com/apache/flink