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 <guruak...@gmail.com> 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 <yanghua1...@gmail.com> 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 <vin...@apache.org> 于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 > > > > > engagement in the short term, by keeping github issues? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Nov 15, 2019 at 7:01 PM vino yang <yanghua1...@gmail.com> > > > 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 <leesf0...@gmail.com> 于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 <vin...@apache.org> 于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 <n3.nas...@gmail.com > > > > > > 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 < > > > yanghua1...@gmail.com> > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
