Completely agree on B. On A I feel the necessity to centralize everything in one place but also without losing the capabilities of Jira. I think we will have to explore tools in eitherways.
Thanks, Sudha On Thu, Jul 15, 2021 at 10:42 PM vino yang <yanghua1...@gmail.com> wrote: > +1 for option B. > > Best, > Vino > > Sivabalan <n.siv...@gmail.com> 于2021年7月16日周五 上午10:35写道： > > > +1 on B. Not sure on A though. I understand the intent to have all in > > one place. but not very sure if we can get all functionality (version, > > type, component, status, parent- child relation), etc ported over to > > github. I assume labels are the only option we have to achieve these. > > Probably, we should also document the labels in detail so that anyone > > looking to take a look at untriaged issues should know how/where to look > > at. If we plan to use GH issues for all, I am sure there will be a lot of > > proliferation of issues. > > > > On Fri, Jul 9, 2021 at 12:29 PM Vinoth Chandar <vin...@apache.org> > wrote: > > > > > Based on this, I will start consolidating more of the cWiki content to > > > github wiki and master branch? > > > > > > JIRA vs GH Issue still probably needs more feedback. I do see the > > tradeoffs > > > there. > > > > > > On Fri, Jul 9, 2021 at 2:39 AM wei li <lw309637...@gmail.com> wrote: > > > > > > > +1 > > > > > > > > On 2021/07/02 03:40:51, Vinoth Chandar <vin...@apache.org> wrote: > > > > > Hi all, > > > > > > > > > > When we incubated Hudi, we made some initial choices around > > > collaboration > > > > > tools of choice. I am wondering if there are still optimal, given > the > > > > scale > > > > > of the community at this point. > > > > > > > > > > Specifically, two points. > > > > > > > > > > A) Our issue tracker is JIRA, while we just use Github Issues for > > > support > > > > > triage. While JIRA is pretty advanced and gives us the ability to > > track > > > > > releases, versions and kanban boards, there are few practical > > > operational > > > > > problems. > > > > > > > > > > - Developers often open bug fixes/PR which all need to be > > continuously > > > > > tagged against a release version (fix version) > > > > > - Referencing JIRAs from Pull Requests is great (we cannot do > things > > > like > > > > > `fixes #1234` to close issues when PR lands, not an easy way to > click > > > and > > > > > get to the JIRA) > > > > > - Many more developers have a github account, to contribute to Hudi > > > > though, > > > > > they need an additional sign-up on jira. > > > > > > > > > > So wondering if we should just use one thing - Github Issues, and > > build > > > > > scripts/hubot or something to get the missing project management > from > > > > > boards. > > > > > > > > > > B) Our design docs are on cWiki. Even though we link it off the > site, > > > > from > > > > > my experience, many do not discover them. > > > > > For large PRs, we need to manually enforce that design and code are > > in > > > > sync > > > > > before we land. If we can, I would love to make RFC being in good > > > shape a > > > > > pre-requisite for landing the PR. > > > > > Once again, separate signup is needed to write design docs or > comment > > > on > > > > > them. > > > > > > > > > > So, wondering if we can move our process docs etc into Github Wiki > > and > > > > RFCs > > > > > to the master branch in a rfc folder, and we just use github PRs to > > > raise > > > > > RFCs and discuss them. > > > > > > > > > > This all also makes it easy for us to measure community activity > and > > > keep > > > > > streamlining our processes. > > > > > > > > > > personally, these different channels are overwhelming to me > at-least > > :) > > > > > > > > > > Love to hear thoughts. Please specify if you are for,against each > of > > A > > > > and > > > > > B. > > > > > > > > > > > > > > > Thanks > > > > > Vinoth > > > > > > > > > > > > > > > > > > -- > > Regards, > > -Sivabalan > > >
