I agree with you that option 1) would be the best for us. Let's keep hoping for the best.
Option 4), as you said, comes with prices. At the moment, I don't have thorough answers to your questions. Just one quick response, I think there's a good chance that we can import current Jira tickets into GH. Jira supports exporting issues with fields that you specified as CSV/XML/... files. With a brief google search, I found some tools that help bulk creating issues in GH. E.g., github-csv-tools [1] is described to support importing issues with title, body, labels, status and milestones from a CSV file. That's probably good enough for us to search/filter the issues in GH, and a link to the Jira ticket can be posted in the GH issue for complete conversation history and other details. Best, Xintong [1] https://github.com/gavinr/github-csv-tools On Mon, Oct 24, 2022 at 3:58 PM Martijn Visser <martijnvis...@apache.org> wrote: > Hi Xintong, > > I'm also not in favour of option 2, I think that two systems will result > in an administrative burden and less-efficient workflow. I'm also not in > favour of option 3, I think that this will result in first time > users/contributors in not-filling their first bug report, user question or > feature request. > > I'm still hoping for option 1 while the discussion is not finished with > Infra. > > If we assume that option 1 won't be possible, then I think option 4 will > be the best-option-left. I'm not necessarily in favour, because of a number > of problems it will introduce: > > 1. I don't think importing current Jira tickets into Github Issues is a > realistic option. So we would have two administrations. Before you create a > new ticket, you should check if it exists both as a Jira ticket and as a > Github Issue. > 2. How would we deal with completing a PR? There must be one > administration leading for the changelog generation (to avoid that you're > missing an item), which could then only be Github Issues. So would we > require all PRs that are merged to exist as a Github Issue? > 3. There's no longer one central administration, which is especially > valuable to track all issues across projects like the different connectors, > Flink ML, Table Store etc. > 4. Our current CI labeling works on the Jira issues, not on the Github > Issues labels. > > Best regards, > > Martijn > > On Mon, Oct 24, 2022 at 7:29 AM Xintong Song <tonysong...@gmail.com> > wrote: > >> Hi devs and users, >> >> As many of you may have already noticed, Infra announced that they will >> soon disable public Jira account signups [1]. That means, in order for >> someone who is not yet a Jira user to open or comment on an issue, he/she >> has to first reach out to a PMC member to create an account for him/her. >> This raises the bar for new contributors and users to participate in >> community interactions, making it necessary for us to consider whether (and >> how) we should change our issue tracking workflows. >> >> I can see a few possible options. >> >> 1. Reaching out to Infra and trying to change their mind on this >> decision. I’ve already been trying this [2], and so far the feedback seems >> unoptimistic. >> 2. Using both Jira (for development issues) & Github Issues (for >> customer-facing issues), as Infra suggested. >> 3. Stay with using Jira only, so that new Jira users need to ask on the >> mailing lists / Slack for creating accounts. >> 4. Migrating to Github Issues completely. >> >> Personally, I’m leaning toward option 4). >> >> TBH, I don’t see any good reason for option 2). I’d expect using two >> different issue tracking tools at the same time would be complex and >> chaotic. Option 3) is probably more friendly to existing developers and >> users, while being less friendly to newcomers. Option 4) on the contrary, >> is more friendly to newcomers, at some migration cost which might be >> non-trivial but once for all. >> >> Github issues have been widely used by many open source projects, >> including Kubernetes, Flink CDC, and Apache projects Iceberg and Airflow. >> With a set of well-designed labels, we should be able to achieve most of >> the Jira functions / features that we currently rely on. Moreover, it >> better integrates the issue tracking and code contributing systems, and >> would be easier to access (I believe there’s more GH users than Jira / >> mailing lists). >> >> All in all, I’d suggest to keep monitoring Infra’s feedback on option 1), >> while taking steps (investigation, workflow & label design) preparing for >> option 4). >> >> Looking forward to hearing what you think about this. >> >> Best, >> >> Xintong >> >> >> [1] https://lists.apache.org/thread/jx9d7sp690ro660pjpttwtg209w3m39w >> >> [2] https://lists.apache.org/thread/fjjtk30dxf6fyoo4q3rmkhh028or40fw >> >>
